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Preface 


The  purpose  of  this  thesis  was  to  develop  a  translator 
called  Style-V  to  translate  IEEE  standard  VHDL  into  a  spe¬ 
cially  styled  VHDL  defined  for  the  Integrated  Design  Automa¬ 
tion  System  (IDAS).  The  two  most  difficult  challenges  of 
the  translation  were  type  conversion  and  function  mapping. 

The  remaining  challenges  were  mostly  textual  conversions . 

My  original  goal  was  to  completely  develop  a  translator 
for  most  of  standard  VHDL.  however,  the  number  and  types  of 
mappings  required  to  fully  implement  this  translator  and  the 
amount  of  work  required  to  analyze,  design,  and  implement  all 
modules  was  very  much  more  than  I  could  finish  in  just  one  thesis 
cycle.  Therefore,  I  reduced  the  scope  of  the  thesis  to  defining 
the  mappings,  analyzing  how  to  do  the  mappings,  performing  a 
manual  simulation  of  a  representative  subset  of  the  map¬ 
pings,  and  implementing  one  mapping. 

I  could  not  have  completed  this  thesis  without  the  support 
of  several  people.  Specifically,  I  thank  Luis  Concha,  Russell 
Milliron,  Donald  Blankenship,  Curtis  Winstead,  Ronald  Comeau,  and 
my  advisor,  Kim  Kanzaki  for  sharing  their  technical  expertise.  I 
also  thank  my  committee  members,  Keith  Jones  and  Mark  Mehalic, 
for  sharing  their  time  and  advise.  I  thank  my  wife  for  her 
constant  support,  especially  in  the  final  hours.  Finally,  I 
thank  God  for  giving  me  the  ability  and  grace  to  complete  this 
effort . 

Dennis  A.  Rumbley 
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Abstract 

This  thesis  provides  an  analysis  and  preliminary  design 
of  Style_V,  a  source- to-source  computer  language  translator. 
Style-V  converts  IEEE  standard  VHDL  into  a  special  style  of 
VHDL  defined  for  a  commercial  tool,  the  Integrated  Design 
Automation  System  (IDAS).  Thirteen  mappings  between  stand¬ 
ard  VHDL  and  the  IDAS  subset  were  identified.  The  mappings 
were  analyzed  using  Domain  Analysis  and  Modern  Structured 
Analysis  techniques.  Four  processes  covering  several  of  the 
mappings  were  completely  analyzed.  One  mapping  to  convert 
CASE  statements  to  IF  statements  was  implemented.  Since  the 
IDAS  restricts  designs  to  bit  logic,  a  method  for  represent¬ 
ing  multilevel  logic  with  bit  logic  was  devised.  Unaccept¬ 
able  multiple  process  architectures  were  converted  to  multi¬ 
ple  single  process  architectures  which  are  acceptable  to 
IDAS.  The  IDAS  microcode  generator  does  not  recognize  user- 
defined  procedures,  but  in  one  case,  mapping  user-defined 
procedures  to  IDAS  defined  procedures  was  not  possible.  In 
general,  this  problem  amounts  to  showing  two  programs  are 
functionally  equivalent.  Exhaustive  testing  was  ruled  out 
since  proving  two  32 -bit  adders  are  equivalent  would  take 
over  11  billion  years  at  100  procedure  runs  per  second.  The 
program  equivalence  problem  was  not  solved  by  this  thesis. 
Useful  results  were  obtained,  though  IDAS  failed  to  work. 
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DESIGN  OF  STYLE-V  - 

A  TRANSLATOR  TO  CONVERT  STANDARD  VHDL 
INTO  A  STYLIZED  FORM  FOR 
AUTOMATED  MICROCODE  GENERATION 

L  Introduction 
1.1  Background 

The  process  of  developing  electronic  components,  espe¬ 
cially  very  large  scale  integrated  (VLSI)  circuits,  has 
matured  during  the  past  decade.  Designers  used  to  plan  out 
a  design,  draw  a  schematic,  and  go  to  an  electronics  labora¬ 
tory  where  they  used  wires  and  breadboards  to  implement  a 
prototype  of  the  design.  If  the  prototype  worked,  the 
design  could  be  finalized  and  readied  for  production. 
Component  prototyping  was  an  especially  error-prone  and 
costly  activity. 

Another  factor  which  caused  component  prototyping  to 
become  costly  and  error-prone  was  the  evolution  of  electron¬ 
ic  hardware.  When  a  designer  could  only  get  hundreds  or 
even  a  few  thousand  components  on  a  single  chip,  an  experi¬ 
enced  designer  could  manage  the  activity.  Now  that  design¬ 
ers  can  place  hundreds  of  thousands  of  components  on  a  chip, 
the  activity  becomes  complex  and  therefore  error  prone. 
Obviously,  the  cost  to  produce  a  correct  design  also  rises 
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with  the  complexity  since  more  time  is  required  to  determine 
the  causes  of  deficiencies  in  the  design. 

A  solution  for  the  aforementioned  problems  has  evolved. 
With  the  advent  of  computer  languages  developed  to  enhance 
the  hardware  design  process,  much  of  the  error-prone  and 
costly  work  could  be  done  by  computer  simulation.  The 
ability  to  simulate  a  design  on  a  computer  made  it  unneces¬ 
sary  for  a  designer  to  spend  the  considerable  time  and  money 
required  to  test  a  design  with  breadboard  methods.  Another 
benefit  was  a  reduction  in  the  number  of  interactions  be¬ 
tween  a  designer  and  the  fabricating  activity  to  produce  a 
correct  component. 

Realizing  the  importance  of  the  hardware  description 
languages  and  their  utility  for  reducing  errors  and  develop¬ 
ment  time  and  cost,  the  Department  of  Defense  developed  the 
VHSIC  (Very  High  Speed  Integrated  Circuit)  Hardware  Descrip¬ 
tion  Language  (VHDL)  as  a  standard  for  DoD  digital  electron¬ 
ic  hardware  development  efforts.  VHDL  provides  any  combina¬ 
tion  of  behavioral,  structural,  or  temporal  views  of  digital 
electronic  design.  The  most  significant  reason  VHDL  was 
more  desirable  than  earlier  hardware  description  languages 
was  its  robust  accounting  for  component  and  circuit  timing 
characteristics.  Timing  is  a  crucial  factor  in  the  physical 
behavior  of  a  circuit  and  accounting  for  timing  during 
development  reduced  design  risk.  As  a  result  of  the  DoD 
actions  and  a  general  need  for  standardization  throughout 
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the  hardware  design  community,  the  Institute  of  Electrical 
and  Electronics  Engineers  (IEEE)  adopted  VHDL  as  an  industry 
standard  in  December  1987.  This  standard  VHDL  has  become 
known  as  IEEE-1076  (Lipsett  and  others,  1989:2). 

VHDL  became  popular  in  the  industry,  and  many  tools 
were  developed  to  work  with  VHDL  to  make  the  hardware 
designer's  job  easier.  These  tools  enhanced  design  capabil¬ 
ities  of  designers  by  providing  services  such  as  design 
analysis,  timing  analysis,  design  library  management,  and 
even  automated  microcode  generation.  However,  some  of  these 
tools  required  a  special  interface,  such  as  a  specially 
styled  VHDL  input  for  the  JRS  Research  Laboratories,  Incor¬ 
porated  Integrated  Design  Automation  System  (IDAS),  which  is 
a  software  system  that  analyzes  algorithms  written  in  the 
Ada  language  and  produces  microcode  based  on  the  Ada  algo¬ 
rithms  for  a  hardware  design  (Software  User's  1989:2). 

To  produce  microcode,  the  IDAS  converts  a  VHDL  design 
into  a  hardware  description  database  (HDD)  format  stored  in 
the  IDAS  database.  It  also  processes  an  application  (or  set 
of  applications)  written  in  a  subset  of  Ada  through  the  IDAS 
compilation  system.  The  information  from  the  hardware 
description  database  and  the  Ada  applications  is  used  by  the 
IDAS  compilation  system  to  produce  microcode  for  the  system 
described  by  the  input  VHDL  code.  A  VHDL  simulation  envi¬ 
ronment  for  testing  the  microcode  is  also  generated.  This 
process  is  depicted  in  Figure  1-1. 
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Figure  1-1.  Ada  to  Microcode  Compilation 
(Integrated  Design,  1988:4) 
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The  IDAS  claims  to  provide  many  benefits.  First,  a 
hardware  designer  need  not  be  concerned  about  optimizing  the 
microcode  to  control  a  hardware  design,  since  the  IDAS  will 
do  that  task.  Second,  since  the  microcode  generated  for  a 
design  is  optimized  for  a  specific  Ada  program,  the  designer 
can  be  confident  the  design  works  for  a  desired  application 
base.  Third,  the  designer  need  not  spend  the  considerable 
amount  of  time  required  to  manually  generate  the  proper 
microcode  for  any  given  hardware  design.  Finally,  the 
designer  can  test  a  given  design  with  the  IDAS  generated  and 
optimized  microcode  to  determine  if  the  design  is 
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satisfactory  or  if  more  design  work  is  required.  Thus,  a 
designer  can  save  time  and  money  while  producing  better 
quality  designs  (Software  User's  1989:4). 

To  use  the  IDAS  system,  a  designer  must  produce  a 
specially  styled  VHDL  input.  The  stylized  VHDL  is  not 
simply  a  change  of  format,  but  in  reality  is  the  use  of  a 
subset  of  the  VHDL  language  along  with  some  restrictions  on 
typing  and  format.  For  instance,  the  VHDL  "case  statement" 
is  not  supported  in  the  stylized  form  (VHDL  Style  Guide 
1989:11,13).  However,  conversion  of  a  "case  statement"  to 
an  "if  statement"  provides  a  satisfactory  solution.  The 
stylized  VHDL  also  does  not  support  sensitivity  lists  in 
process  statements,  but  it  handles  sensitivities  by  using  a 
required  "wait  statement"  as  the  first  statement  of  a  proc¬ 
ess  (VHDL  Style  Guide  1989:12).  These  along  with  several 
other  restrictions  make  use  of  the  stylized  VHDL  as  a  design 
tool  less  desirable  than  use  of  the  standard  IEEE  VHDL. 

1.2  Problem  Statement 

The  IDAS  takes  as  input  a  highly  stylized  form  of  VHDL, 
converts  the  VHDL  into  a  Hardware  Description  Database 
(HDD),  and  uses  the  HDD  "in  the  Ada  to  Microcode  Compiler 
retargeting  process"  (VHDL  Style  Guide  1989:1)  to  produce 
microcode  for  the  hardware  described  by  the  VHDL.  However, 
VHDL  programmers  do  not  naturally  produce  stylized  VHDL 
code.  The  freeform  IEEE  standard  VHDL  code  produced  by 
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designers  must  then  be  translated.  The  translation  process 
consists  of  analyzing  the  standard  VHDL  code  and  translating 
it  into  the  subset  of  VHDL  accepted  by  IDAS.  Hand  transla¬ 
tions  of  even  simple  designs  would  undoubtedly  result  in 
several  iterations  to  ensure  a  correct  translation.  There¬ 
fore,  an  automated  system  to  translate  standard  freeform 
VHDL  into  the  stylized  form  is  required  to  eliminate  the 
need  for  programmers  to  manually  translate  their  designs. 

1.3  Research  Objective 

This  thesis  has  researched  and  analyzed  an  automated 
tool  to  translate  freeform  VHDL  code  into  JRS  stylized  VHDL 
code  acceptable  for  input  to  the  IDAS .  The  automated  tool 
is  called  the  Style -V  Translator. 

1.4  Overview  of  Current  Knowledge 

Since  the  focus  of  this  research  was  to  design  a  VHDL 
translator,  the  direction  of  the  literature  search  (Chapter 
2)  concentrated  on  computer  language  translation,  compiler 
theory,  and  related  topics. 

Much  work  has  been  done  in  the  past  thirty  years  in  the 
computer  language  translation  field.  The  literature  review 
concentrated  on  articles  and  books  which  give  insight  into 
semantic  and  syntactic  translation  methods  and  procedures . 
Since  many  methods  exist,  the  literature  review  helped 
narrow  the  field  to  the  methods  best  suited  for  the  Style -V 
hardware  description  language  translator. 
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Most  computer  language  translators  translate  one  pro¬ 
gramming  language  into  another.  Some  translate  between 
dialects  of  the  same  language.  In  one  case,  a  bidirectional 
translator  was  built  which  could  translate  between  two 
programming  languages . 

The  main  lesson  to  learn  from  the  existing  translators 
is  the  necessity  for  an  intermediate  form  to  use  during 
translation.  An  appropriate  intermediate  form  consists  of  a 
canonical  representation  which  is  general  and  extensive 
enough  to  represent  constructs  available  in  the  languages 
being  translated.  A  translator  then  need  only  be  able  to 
translate  from  a  source  language  into  the  canonical  form  and 
from  the  canonical  form  to  the  target  language. 

For  simple  translations  between  dialects  of  a  language, 
the  basic  constructs  of  the  general  language  may  serve  as 
the  canonical  form.  The  translator  needs  to  be  capable  of 
translating  high-level  constructs  into  more  general  con¬ 
structs  of  the  same  language.  Also,  some  reformatting  of 
language  sentence  structure  may  be  required. 

1.5  Assumptions 

Whenever  a  major  research  effort  is  undertaken,  the 
researcher  must  realistically  project  the  expectations  of 
the  research,  including  limitations  on  the  final  product. 
This  thesis  is  no  different.  The  following  assumptions 
document  the  expected  results  of  this  thesis  and  the  expect¬ 
ed  limitations. 
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Since  VHDL  is  an  extensive  hardware  description  lan¬ 
guage,  describing  levels  of  detail  ranging  from  system  level 
to  gate  level,  not  enough  time  was  available  for  this  thesis 
effort  to  develop  a  translator  that  completely  translated 
all  VHDL  capabilities .  A  more  reasonable  expectation  was  to 
translate  VHDL  into  the  stylized  form  for  designs  down  to 
the  component  level.  A  component  here  is  a  collection  of 
gate -level  primitives  which  form  a  component  and  perform  a 
register-transfer  language  function  (for  example,  add) . 

This  level  of  detail  was  sufficient  for  the  IDAS  which  uses 
the  stylized  VHDL.  Additionally,  the  considerable  complex¬ 
ity  of  VHDL  and  the  restricted  nature  of  the  subset  compris¬ 
ing  the  stylized  VHDL  caused  the  research  to  center  on 
demonstrating  the  feasibility  for  translating  a  freeform 
input  to  the  stylized  version.  Therefore,  component  level 
translation  of  a  simple  CPU  was  the  first  goal  of  this 
thesis  followed  by  the  translation  of  portions  of  the  Float¬ 
ing  Point  Application  Specific  Processor  (FPASP)  chip  being 
jointly  developed  by  Rome  Laboratory  and  the  Air  Force 
Institute  of  Technology  (AFIT) .  By  completing  these  trans¬ 
lations,  enough  synthesis  of  VHDL  into  the  stylized  subset 
was  accomplished  to  demonstrate  concept  feasibility.  A 
follow-on  thesis  effort  will  be  required  to  complete  the 
STYLE-V  Translator  for  all  feasible  mappings  of  VHDL  con¬ 
structs  . 
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A  second  assumption  was  that  JRS'  IDAS  would  work 
properly.  The  IDAS  was  a  system  developed  for  the  DoD  under 
a  Navy  contract  to  JRS  Research  Laboratories,  Incorporated. 
Contact  with  agencies  known  to  have  used  the  IDAS  indicated 
certain  parts  of  the  IDAS  work  well;  however,  none  of  the 
agencies  contacted  used  the  IDAS  in  the  manner  required  for 
this  research. 

Another  assumption  was  that  future  releases  of  the  JRS 
IDAS  system  would  continue  to  use  the  stylized  format  of 
VHDL  as  described  by  JRS.  If  the  style  were  changed  during 
this  research  effort,  the  change  would  have  had  a  major 
impact.  The  research  would  have  continued,  but  potentially 
fewer  features  would  have  been  implemented  should  such  a 
change  have  occurred. 

1.6  Methodology 

Thorough  research  was  paramount  to  the  successful 
completion  of  this  effort.  Manual  and  automated  literature 
searches  provided  the  basis  for  the  design  and  implementa¬ 
tion  of  the  Style -V  translator  by  providing  references  to 
literature  containing  information  regarding  the  most  modern 
techniques  for  development  and  implementation  of  translator 
software  systems. 

After  enough  information  was  gathered  through  the 
literature  review,  design  followed.  Design  began  with  a 
domain  analysis  of  the  problem.  Experts  on  the  IDAS  system. 
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the  hardware  development  process,  and  FPASP  design  were 
interviewed. 

Following  domain  analysis,  requirements  analysis  pro¬ 
duced  what  became  the  system  specifications  for  Style-V. 

The  requirements  analysis  process  consisted  of  creating  a 
context  diagram  of  the  proposed  system.  As  the  data  flow 
for  the  system  was  analyzed,  the  initial  context  diagram  was 
decomposed  into  lower  levels  of  detail.  The  system  analysis 
methods  described  above  were  originally  espoused  by  Yourdon 
(Yourdon  1979  &  1989)  and  by  Gane  and  Sarson  (Gane  and 
Sarson  1979)  and  have  been  shown  successful  by  many  large- 
scale  software  system  implementations. 

The  next  step  was  a  functional  demonstration  of  the 
translation  process.  Manual  desktop  implementations  of 
portions  of  the  Style-V  system  showed  the  feasibility  of 
automating  certain  parts  of  Style-V  and  the  apparent  infea¬ 
sibility  of  automating  other  parts. 

One  process  of  Style-V  was  chosen  for  prototyping  to 
demonstrate  a  part  of  the  translator  which  could  be  fully 
automated.  Though  it  was  a  rapid  prototype,  care  was  taken 
to  encapsulate  the  modules  of  the  process.  Properly  encap¬ 
sulated  software  modules  hide  their  inner  workings  and 
interact  with  the  remainder  of  the  system  through  well 
defined  interfaces.  Since  the  implemented  modules  of  the 
Style-V  translator  were  written  in  C,  these  interfaces  took 
the  form  of  function  calls.  Thus,  a  change  tr  the  internal 
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workings  of  a  function  is  transparent  to  the  rest  of  the 
system.  Therefore,  changes  or  additions  to  the  Style-V 
Translator  are  localized  and  easily  done. 

1.7  Thesis  Overview 

Chapter  1  provides  an  introduction  to  the  need  for  an 
automated  tool  to  translate  standard  VHDL  into  a  stylized 
format.  The  sections  of  this  chapter  cover  pertinent  back¬ 
ground  information,  a  problem  statement,  the  research  objec¬ 
tive,  an  overview  of  current  knowledge,  some  key  assump¬ 
tions,  the  general  methodology  used,  and  an  overview  of  the 
contents  of  the  written  thesis. 

Chapter  2  reviews  the  literature  pertinent  to  the 
completion  of  this  thesis  effort.  Many  of  the  books  and 
articles  read  contained  information  crucial  for  the  under¬ 
standing  and  use  of  modern  software  development  practices 
and  knowledge  necessary  to  understand  and  develop  Style-V. 
Besides  an  introductory  section.  Chapter  2  includes  sections 
on  translation  fundamentals,  lexical  analysis,  parsing, 
grammar  disambiguation,  examples  of  translators,  and  a 
summary  section. 

Chapter  3  documents  the  analysis  of  the  Style-V  trans¬ 
lator.  The  sections  provide  an  introduction  to  requirements 
analysis,  a  review  of  available  methods,  a  discussion  of  the 
method  chosen,  the  process  of  domain  analysis  for  Style-V, 
the  system  analysis  for  Style-V,  and  a  review  section. 
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Chapter  4  documents  the  manual  desktop  implementation 
of  the  Style -V  translator.  The  sections  provide  an  intro¬ 
duction,  a  discussion  on  the  selection  of  the  processes  of 
Style -V  chosen  for  implementation,  the  description  of  the 
implementations,  a  discussion  of  the  lessons  learned  from 
the  desktop  implementation  process,  and  a  review  section. 

Chapter  5  discusses  the  results,  conclusions,  and 
recommendations  resulting  from  this  research  effort. 

Appendix  A  contains  a  simple  VHDL  hardware  system 
description  used  to  demonstrate  the  concept  of  using  JRS 
IDAS  procedures  to  produce  a  working  machine . 

Appendix  B  contains  extracts  from  the  Floating  Point 
Application  Specific  Processor  (FPASP)  used  as  a  real  world 
example  for  translating  standard  VHDL  into  a  stylized  VHDL 
subset.  Since  this  appendix  includes  proprietary  Air  Force 
design  data,  it  is  maintained  in  Volume  II  of  this  thesis 
and  distribution  is  limited.  See  the  Appendix  B  tab  of  this 
volume  for  more  details . 

Appendix  C  contains  the  results  of  applying  Style-V 
translations  to  the  FPASP  code  sections  of  Appendix  B. 

Since  this  appendix  includes  proprietary  Air  Force  design 
data,  it  is  maintained  in  Volume  II  of  this  thesis  and 
distribution  is  limited.  See  the  Appendix  C  tab  of  this 
volume  for  more  details. 

Appendix  D  contains  the  implemented  modules  of  the 
Style-V  Translator. 
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II.  Literature  Review 


2.0  Introduction 

This  literature  review  explores  current  literature  on 
topics  critical  to  the  successful  completion  of  this  thesis. 
The  topics  covered  concern  issues  related  to  translating 
computer  programs  from  one  form  to  another. 

Some  of  the  articles  deal  with  maintaining  the  meaning 
of  an  input  program  for  use  in  generating  an  output  program. 
Other  articles  deal  with  the  various  components  of  transla¬ 
tion  systems,  specifically  the  lexical  analyzer  and  parser. 
The  lexical  analyzer,  often  called  a  scanner,  reads  an  input 
program  and  passes  each  token  it  recognizes  to  the  parser. 
The  parsing  process  deals  with  comparing  an  input  stream  of 
tokens  against  a  language's  grammar  in  such  a  way  to  deter¬ 
mine  the  meaning  indicated  by  the  input  (Allman,  1988:76). 

To  accomplish  this  task,  the  parser  checks  the  syntactic 
correctness  of  the  input.  Given  the  input  if;  syntactically 
correct,  the  parser  then  uses  semantic  routines  to  either 
generate  an  intermediate  representation  or  generate  the 
final  output  of  the  translator.  If  an  intermediate  inter¬ 
pretation  is  generated,  a  code  generator  produces  the  trans¬ 
lated  program  (Fisher  and  LeBlanc,  1988:11-13,215-220;  Aho 
and  Ullman,  1977:7,19,254). 
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2.1  Translation  Fundamentals 


Some  aspects  of  language  translation  can  be  classified 
as  fundamental  to  the  translation  process.  Any  effort  which 
produces  a  translator  must  address  the  fundamental  issues  of 
language  translation.  Style-V  is  no  exception. 

2.1.1  Analysis  and  Synthesis .  Analysis  and  synthesis 
are  the  two  actions  required  for  a  translator  to  convert  an 
algorithm  in  a  source  language  into  a  similar  algorithm  in  a 
target  language.  Analysis  determines  what  actions  are 
ultimately  required  by  the  implementation  in  the  target 
language.  Synthesis  is  the  process  of  transforming  the 
source  statements  into  direct  execution  or  a  target  language 
form  (Calingaert,  1988:5). 

Analysis  occurs  in  three  distinct  stages.  The  first 
stage  is  lexical  analysis  where  words  of  the  source  language 
are  recognized  by  an  examination  of  the  characters  found  in 
the  input  text.  The  second  stage,  syntactic  analysis, 
examines  and  determines  the  correctness  of  the  structure  of 
the  source  language  input.  When  the  idea  of  grammar  (the 
proper  association  of  symbols  in  a  language)  is  incorporat¬ 
ed,  the  syntactic  analysis  is  known  as  parsing.  The  final 
stage  of  analysis,  semantic  processing,  entails  associating 
the  semantic  information  (meaning)  of  the  input  tokens  in 
such  a  way  that  the  meaning  can  be  maintained  in  and  trans¬ 
formed  to  a  new  representation  (intermediate  code  or  the 
target  language)  (Calingaert,  1988:5,235-6). 
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2.1.2  Compatibility  of  Languages .  Commonalities  and 
differences  of  languages  must  be  precisely  defined  if  one 
hopes  to  successfully  translate  between  them.  These  defini¬ 
tions  are  particularly  important  when  translating  between 
dialects  of  the  same  language.  Fortunately,  techniques 
which  define  parts  of  a  language  in  terms  of  itself  lessen 
the  definition  effort  ( Krieg-Briickner ,  1984:299). 

Given  two  languages  Alang  and  Blang,  if  the  language 
concepts  of  the  sublanguages,  Asublang  (the  sublanguage  for 
a  language  Alang)  and  Bsublang  (the  sublanguage  for  a  lan¬ 
guage  Blang),  correspond  in  a  one-to-one  manner,  then  Asub¬ 
lang  and  Bsublang  are  said  to  be  directly  compatible. 
Additionally,  if  the  concepts  of  a  language,  Aotherlang  (a 
language  other  than  Asublang  or  Bsublang),  are  mappable  to 
Asublang,  then  Aotherlang  is  said  to  be  indirectly  compati¬ 
ble  with  Bsublang. 

If  Asublang  is  complete  in  the  sense  that  all  concepts 
of  Alang  can  be  mapped  into  it,  and  Bsublang  is  complete  in 
the  same  respect  with  Blang,  the  Alang  can  be  mapped  to 
Blang.  A  problem  exists  when  concepts  in  the  language  Alang 
cannot  be  mapped  to  Asublang,  at  which  point  Alang  cannot  be 
fully  mapped  to  Bsublang,  and  therefore  the  languages  Alang 
and  Bl^.ng  are  said  to  be  incompatible  and  translations 
between  them  are  not  generally  possible  (Krieg-Briickner, 

1984 : 300) . 
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If  certain  restrictions  exist  in  one  language,  these 
restrictions  may  require  an  "applicability  condition"  hold 
for  the  other  language  being  translated  for  a  one-to-one 
translation  to  be  possible.  Krieg-Briickner  gave  the  example 
of  the  for-loop  variable  in  Ada  and  Pascal.  If  a  direct 
translation  is  to  be  obtained,  the  variable  must  not  be 
assigned  values  outside  the  loop  body  in  both  language 
implementations  (Krieg-Briickner,  1984:303). 

Another  key  point  in  having  the  ability  to  directly 
translate  between  sublanguages  is  that  the  sublanguages  must 
have  a  certain  level  of  expressive  power.  This  expressive 
power  between  sublanguages  enables  one  sublanguage  to  ex¬ 
press  concepts  contained  in  the  other  sublanguage  (Krieg- 
Briickner,  1984:303). 

The  semantic  mapping  from  Alang  to  Asublang  can  be 
thought  of  as  a  homomorphism  (they  look  similar)  and  the 
equivalence  of  the  semantics  can  be  proven  using  the  seman¬ 
tic  definitions  of  the  languages.  Asublang  is  a  "subset" 
language  of  Alang,  and  all  Alang  constructs  can  map  to 
Asublang  constructs.  The  translation  of  Asublang  to  Bsub- 
lang  would  be  an  isomorphism  (they  look  different)  using  an 
equivalent  semantic  definition  kernel  (Krieg-Briickner, 

1984 : 304) . 

2.1.3  Two  Fundamental  Approaches .  The  research  for 
this  thesis  effort  determined  that  two  fundamental  approach¬ 
es  to  program  translation  currently  exist.  The  most  common 
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approach  is  transliteration  and  refinement.  An  alternate 
method  is  to  use  abstraction  and  reimplementation .  The 
remainder  of  this  section  describes  these  approaches  and 
provides  their  respective  advantages  and  disadvantages . 

The  approach  of  transliteration  and  refinement  is  based 
on  a  direct  translation  of  statements  in  a  source  language 
to  semantically  equivalent  statements  in  a  target  language. 
This  is  done  by  a  translating  statements  in  isolation  from 
the  overall  context  of  the  program.  The  output  can  be  in 
the  target  language  or  a  semantically  similar  intermediate 
language.  The  refinement  step  applies  "correctness  preserv¬ 
ing  transformations"  to  the  generated  target  code  to  improve 
the  quality  of  it  (Waters,  1986:2). 

Advantages  of  transliteration  and  refinement  include  a 
divide  and  conquer  approach,  localized  nature  of  the  trans¬ 
lations,  and  ease  of  constructing  families  of  translators. 
The  transliteration  step  need  not  be  concerned  with  later 
refinements  --  the  basic  goal  is  to  obtain  a  semantically 
correct  translation.  Since  transliteration  takes  a  local¬ 
ized  approach  to  translation,  the  knowledge  needed  for 
translation  is  easily  determined  since  it  need  not  consider 
how  special  combinations  of  a  target  language  might  imple¬ 
ment  special  combinations  of  the  source  language.  Finally, 
translators  which  use  similar  methods  of  either  translitera¬ 
tion  or  refinement  can  be  easily  adapted  to  similar  lan¬ 
guages  (Waters,  1986:7). 
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Unfortunately,  transliteration  and  refinement  have  some 
disadvantages .  One  of  the  main  disadvantages  is  that  the 
refinement  process  is  complicated  because  the  translitera¬ 
tion  is  a  localized  translation  which  often  results  in 
convoluted  code  in  the  target  language.  Additionally,  it  is 
not  always  practical  to  translate  one  construct  of  a  source 
language  into  a  construct  of  the  target  language.  Some¬ 
times,  a  source  language  contains  a  primitive  which  is  not 
supported  in  the  target  language  and  transliteration  cannot 
handle  this  problem.  Finally,  current  translators  suffer 
from  the  problem  of  being  able  to  straightforwardly  trans¬ 
late  certain  constructs  most  of  the  time,  but  on  occasion 
they  incorrectly  translate  the  constructs  when  the  transla¬ 
tion  is  difficult  or  impossible  (Waters,  1986:8-9). 

Translation  can  alternatively  be  done  via  abstraction 
and  reimplementation.  The  abstraction  process  first  ana¬ 
lyzes  the  program  globally  and  uses  this  analysis  to  gain  an 
understanding  of  the  algorithms  in  the  source  program.  The 
reimplementation  process  uses  the  knowledge  of  the  source 
program  algorithms  to  implement  equivalent  algorithms  in  the 
target  language.  Unlike  transliteration,  abstraction  does 
not  require  a  knowledge  of  the  target  language  when  analyz¬ 
ing  the  source  language  (Waters,  1986:10). 

One  of  the  advantages  of  abstraction  and  reimplementa¬ 
tion  over  transliteration  and  refinement  is  the  ability  to 
satisfy  the  subsidiary  goals  of  language  translation  --a 
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readable  translation.  This  is  a  natural  consequence  of  the 
main  goal  of  abstraction  --to  simplify  reimplementation.  A 
second  advantage  of  abstraction  and  reimplementation  is 
ability  to  translate  any  possible  translation  task.  Final¬ 
ly,  "translation  via  abstraction  and  reimplementation  lends 
itself  to  the  construction  of  families  of  translators" 
(Waters,  1986:16). 

Some  of  the  problems  of  abstraction  and  reimplementa¬ 
tion  include  a  lack  of  completeness,  the  practicality  of 
translation,  and  the  complicated  nature  of  the  process. 

When  it  is  not  practical  to  use  abstraction  and  reimplemen¬ 
tation,  a  translator  could  fall  back  to  a  process  of  trans¬ 
literation  in  most  cases  since  the  problems  of  abstraction 
and  reimplementation  are  orthogonal  to  the  problems  of 
transliteration  and  reimplementation  --  in  other  words,  when 
it  is  not  practical  to  use  one  method,  the  translation  at 
that  point  will  usually  be  easier  using  the  other  method. 
Since  abstraction  and  reimplementation  is  significantly  more 
complicated  than  transliteration  and  reimplementation,  when 
transliteration  is  practical  and  little  refinement  is  re¬ 
quired,  the  method  of  choice  is  probably  transliteration  and 
refinement  (Waters,  1986:16). 

Calingaert  claims  that  "translation  from  one  machine- 
independent  language  to  another  is  rarely  feasible ." (Caling¬ 
aert,  1988:330).  However,  during  this  research  effort. 
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several  examples  of  source-to-source  translators  were  found. 
A  sampling  of  such  translators  are  discussed  in  Section  2.5. 

2.2  Lexical  Analysis 

Lexical  analysis  is  the  process  of  taking  an  input 
string  and  converting  it  into  a  sequence  of  tokens.  Normal¬ 
ly,  some  other  program  will  use  the  tokens  produced  by  the 
lexical  analyzer  for  further  processing  (Fox,  1987:51). 

Various  methods  exist  to  generate  a  lexical  analyzer. 
Some  lexical  analyzers  are  "hand-generated"  by  a  programmer. 
Hand-generated  lexical  analyzers  can  be  very  efficient  but 
can  be  difficult  to  construct.  Other  lexical  analyzers  are 
generated  using  some  type  of  lexical  analyzer  generating 
program.  Normally,  a  programmer  can  generate  a  lexical 
analyzer  much  quicker  and  easier  with  an  automated  tool  than 
by  hand  generating  techniques . 

Numerous  lexical  analyzer  generators  exist.  Probably 
the  most  famous  and  most  widely  used  lexical  analyzer  gener¬ 
ator  is  the  program  called  LEX  written  by  Lesk  in  1975 
(Lesk,  1975) .  LEX  considers  an  input  string  of  characters 
and  compares  them  with  the  definitions  of  acceptable  tokens. 
The  token  definitions  are  in  the  form  of  regular  expres¬ 
sions  . 

LEX  matches  the  longest  possible  token  as  it  reads  an 
input  string.  Normally,  tokens  in  the  input  string  are 
delimited  by  white  space  characters  (blank  or  tab)  or  the 
newline  character.  LEX  identifies  tokens  by  returning  an 
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integer  value  through  the  function  YYLEX  and  keeps  the 
string  value  of  the  token  in  the  variable  YYLVAL. 

The  capabilities  of  LEX  exceed  those  of  a  simple  lexi¬ 
cal  analyzer  (Fox,  1987:53,55).  When  a  token  is  recognized, 
LEX  provides  a  capability  for  a  programmer  to  specify  pro¬ 
gramming  language  (usually  C)  statements  to  be  executed  for 
each  token  that  is  recognized.  The  actions  specified  by  the 
programmer  are  in  addition  to  LEX's  identifying  the  token 
and  string  value  as  stated  above.  The  capability  of  execut¬ 
ing  programming  statements  upon  recognition  of  tokens  makes 
LEX  a  powerful  tool  for  lexical  analysis  and  text  process¬ 
ing  . 

Besides  LEX's  power  and  flexibility,  LEX  is  a  readily 
available  resource  at  AFIT  and  on  other  systems  used  for 
this  thesis.  Therefore,  due  to  the  availability  and  power 
of  LEX,  it  was  seriously  considered  for  use  in  the  develop¬ 
ment  of  STYLE-V. 

2.3  Parsing 

Computer  languages  are  generated  from  Context-Free 
Grammars  (CFG) .  A  CFG  is  a  collection  of  terminal  symbols 
which  represent  the  alphabet  legal  for  a  language,  nontermi¬ 
nal  symbols  which  are  derived  by  some  combination  of  termi¬ 
nal  symbols,  and  a  finite  set  of  productions  which  are  the 
rules  that  define  how  nonterminal  symbols  are  derived  in 
terms  of  terminal  and  nonterminal  symbols  (Cohen,  1986:247). 
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An  analogy  is  to  think  of  a  program  as  a  paragraph. 

The  computer  language  statements  in  the  program  are  the 
sentences  of  the  paragraph.  The  identifiers  and  symbols  in 
the  statements  are  the  words  of  the  sentences.  Finally,  the 
characters  composing  the  identifiers  and  symbols  represent 
the  alphabet  of  the  language. 

The  rules  which  determine  if  a  "sentence"  of  a  computer 
language  is  correct  are  the  syntax  rules.  The  job  of  a 
parser  is  to  receive  tokens  (words)  from  the  lexical  analyz¬ 
er  and  apply  the  syntax  rules  to  the  sentences  formed  by  the 
words  to  determine  if  the  sentences  are  legal. 

Semantic  processing,  on  the  other  hand,  deals  with  what 
a  given  sentence  (or  even  program)  means.  Once  a  parser 
determines  a  portion  of  the  input  is  syntactically  correct, 
it  can  call  semantic  routines  to  assess  the  meaning  of  the 
input. 

Sideri  (and  others)  discussed  the  use  of  attribute 
grammars  with  no  restrictions  on  the  dependencies  of  the 
attributes  used  for  parsing.  An  attribute  grammar  is  recog¬ 
nized  by  the  association  of  attributes  to  the  nonterminal 
symbols  of  a  CFG,  the  "functions  on  the  attributes,  and 
conditions  over  the  attributes"  (Sideri  and  others,  1989:91- 
92)  . 

Using  attribute  grammars,  Sideri  proposed  a  Semantical¬ 
ly  Driven  Parsing  method  for  context-free  languages.  An 
attribute  grammar  is  defined  as  a  reduced  CFG,  a  finite  set 
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of  attributes,  the  domains  of  the  attributes,  a  set  of 
semantic  rules,  and  a  set  of  semantic  conditions.  The 
semantic  condition  for  each  production  is  either  satisfied 
and  a  correct  parse  is  realized,  or  the  semantic  rules 
operating  on  the  attributes  violated  a  constraint  on  the 
attributes,  thus  signifying  an  incorrect  parse  of  a  produc¬ 
tion  (Sideri  and  others,  1989:91). 

The  semantic  assessment  of  the  input  strings  is  accom¬ 
plished  during  the  parsing  of  the  input  stream.  With  this 
method,  meaning  is  only  assigned  to  semantically  correct 
input  strings  and  any  incorrect  string  is  rejected,  an 
advantage  over  other  methods  that  form  and  search  parse 
trees  for  all  input  strings.  Also,  attribute  reevaluation 
between  multiple  parse  trees  for  the  same  input  string  is 
avoided  (Sideri  and  others,  1989:91). 

2.4  Disambiguating  Grammars 

During  syntactic  analysis,  the  productions  defined  by  a 
grammar  may  lead  to  conflicting  reductions.  Normally,  some 
standard  or  default  reduction  is  chosen  over  the  other 
conflicting  reductions.  Since  a  standard  or  default  produc¬ 
tion  is  reduced,  the  other  productions  are  ignored.  There¬ 
fore,  because  conflicting  reductions  are  present,  the  gram¬ 
mar  is  ambiguous .  An  example  of  ambiguous  productions  is : 

P  - ->  c 

Q  - ->  c 
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where  the  parser  does  not  know  whether  to  reduce  P  or  reduce 
Q  (Ganapathi,  1989:25). 

Ganapathi  provides  a  solution  to  disambiguate  the  way 
parsers  reduce  productions  that  only  involves  modification 
of  the  parser  driver,  so  Ganapathi 's  solution  is  applicable 
to  presently  available  off-the-shelf  parser  generators. 

Using  Ganapathi 's  method,  disambiguating  predicates  can  be 
added  and  disambiguation  is  done  dynamically  (Ganapathi, 
1989:25,29-30) . 

According  to  Ganapathi,  a  production  may  have  many 
predicates.  However,  at  least  one  and  only  one  predicate  of 
a  production  must  evaluate  to  true  and  all  other  predicates 
of  the  production  must  evaluate  to  false.  (Ganapathi, 
1989:25-26) . 

Ganapathi 's  method  is  reasonably  simple  to  implement 

and  does  not  require  rewriting  the  parser  generator.  When 

implementing  Ganapathi 's  method, 

conflicting  productions  in  the  grammar  are  expanded 
with  distinct  terminal  symbols  and  an  ?  production  is 
introduced  to  invoke  a  predicate -routine  and  select  a 
production.  (Ganapathi,  1989:29) 

The  following  example  shows  the  ease  of  implementing 

Ganapathi ' s  method.  Given  the  ambiguous  productions: 

PI:  A  -->  C 

P2:  B  -->  C 

replace  them  by  productions  using  look-ahead  disambiguation. 
Lookahead  disambiguation  is  added  by  rewriting  the  ambiguous 
productions  with  a  new  nonterminal  and  disambiguating 
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terminals  at  the  end  of  the  ambiguous  portion  of  the  produc¬ 
tion.  The  new  nonterminal  is  then  formed  into  a  production 
and  the  disambiguation  is  triggered.  The  resulting  produc¬ 
tions  are: 


PI:  A  -->  C  V  Ta 

P2:  B  -->  C  V  Tb 

P3 :  V  -->  ?  disambiguate (Ta, Tb) 

The  correct  choice  between  PI  and  P2  will  occur  when  P3 
reduces  and  the  disambiguate  predicate  triggers.  The  predi¬ 
cate  reduces  by  considering  the  context  or  by  using  condi¬ 
tions  defined  by  the  system  developer  (Ganapathi,  1989:30). 

In  the  conclusion  of  the  article,  Ganapathi  points  out 
two  benefits  of  including  semantic  predicates  as  context 
sensitive  parts  of  the  grammar.  First,  the  inclusion  of  the 
predicates  "contributes  to  an  overall  gain  in  convenience" 
for  the  grammar  writer  (Ganapathi,  1989:32).  Finally, 
"resolution  by  a  linear  ordering  of  predicates  permits 
incremental  addition  of  productions  in  a  grammar" 

(Ganapathi,  1989:32). 

2.5  Examples  of  Existing  Translator  Systems 

As  part  of  this  research  effort,  a  review  of  existing 
language  translators  provided  invaluable  insight  into  poten¬ 
tial  methods  for  implementing  Style-V.  The  purpose  of  this 
section  is  to  provide  a  review  of  the  articles  and  books 
researched  for  knowledge  to  complete  this  thesis. 
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2.5.1  PasTran 


A  Pascal  to  Ada  Translator.  PasTran 


is  a  translator  developed  for  the  purpose  of  translating 
Pascal  programs  to  the  Ada  programming  language.  Since 
PasTran  translates  95  percent  of  the  standard  Pascal  lan¬ 
guage,  if  the  Pascal  programs  are  in  standard  Pascal,  the 
conversion  is  virtually  automatic  and  most  required  editing 
is  for  esthetic  reasons  only  (Owen,  1987:423,425). 

The  translator  takes  three  passes  to  process  a  Pascal 
program.  The  first  pass  analyzes  the  syntax  of  the  Pascal 
program.  The  second  pass  analyzes  the  semantics.  The  third 
and  final  pass  generates  the  translated  Ada  code  (Owen, 
1987:425) . 

During  the  translation  process,  PasTran  generates  error 
messages  and  provides  the  user  with  the  option  of  terminat¬ 
ing  the  translation  process  or  continuing.  This  allows  a 
user  to  let  PasTran  translate  as  much  as  possible  automati¬ 
cally.  The  user  can  then  hand  translate  the  portions  Pas¬ 
Tran  could  not  understand.  This  option  allows  the  transla¬ 
tion  of  nonstandard  Pascal  and  the  few  standard  constructs 
PasTran  is  unable  to  handle  (Owen,  1987:425). 

A  final  item  of  note  about  PasTran  is  it's  ability  to 
handle  constructs  of  Pascal  for  which  no  equivalent  Ada 
construct  exists,  specifically,  the  Pascal  record  WITH 
clause.  PasTran  creates  a  new  identifier  and  uses  the  Ada 
dot  notation  to  emulate  the  Pascal  WITH  construct. 
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2.5.2  PCC  --  A  Pascal  to  C  Translator.  PCC  is  a 
Pascal  to  C  translator  written  in  the  C  programming  language 
for  portability.  It  has  been  ported  to  several  configura¬ 
tions.  PCC  satisfies  two  main  tasks.  First,  applications 
written  in  standard  Pascal  which  now  need  further  features 
added  (features  not  available  in  Pascal)  may  be  converted  to 
C  which  has  the  required  language  features.  Second,  with 
PCC  it  is  possible  to  port  Pascal  programs  to  a  newly  de¬ 
veloped  computer  system  which  has  a  C  compiler  but  not  one 
for  Pascal  (Bothe  and  others,  1989:60). 

The  requirements  for  PCC  were  derived  from  the  two  main 
uses  described  above.  Since  the  C  programs  generated  by  PCC 
will  be  used  for  further  program  development,  the  trans¬ 
formed  C  code  must  be  comprehensible.  Also,  the  generated  C 
programs  must  be  efficient  to  maintain  the  efficiency  of  the 
source  Pascal  programs .  Some  technology  must  exist  to 
handle  the  dialects  of  Pascal  as  many  dialects  exist  with 
extensions  to  the  standard  language,  the  most  famous  being 
Turbo  Pascal.  Since  the  translator  is  being  developed  as  a 
translation  tool,  it  must  be  portable.  Finally,  the  trans¬ 
lator  must  be  efficient  since  not  all  Pascal  programs  run 
through  may  be  fully  tested  --  the  case  when  PCC  is  used  as 
a  development  tool  for  new  Pascal  programs  until  a  Pascal 
compiler  is  available  (Bothe  and  others,  1989:61). 

Comprehensible  C  code  is  generated  by  PCC  because  the 
PCC  system  follows  four  principles.  The  first  principle  PCC 
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observes  is  to  preserve  the  structure  of  the  original  Pascal 
program  in  the  translated  C  program.  The  second  principle 
involves  using  rules  for  translating  language  constructs 
that  maintain  comprehensibility.  Third,  identifiers  from 
the  Pascal  source  should  be  analogous  in  the  translated  C 
code.  Fourth,  and  finally,  Pascal  comments  must  be  trans¬ 
lated  to  equivalent  C  comment  statements  (Bo the  and  others, 
1989:62) . 

One  feature  of  Pascal  that  makes  abiding  by  the  princi¬ 
ple  of  maintaining  original  structure  is  the  use  of  local 
procedures  or  functions.  Since  C  does  not  have  this  feature 
(all  functions  are  global),  maintaining  the  functionality 
will  be  possible  but  maintaining  the  original  structure  is 
not  (Bothe  and  others,  1989:62). 

Improving  the  efficiency  of  a  translation  is  sometimes 
difficult  depending  on  the  optimization  scheme  chosen. 
Sometimes  complex  optimization  attempts  achieve  very  little 
real  gain  in  efficiency.  For  PCC,  it  was  decided  to  imple¬ 
ment  local  optimizations,  which  are  simple  and  obvious,  and 
leave  further  optimization  to  the  discretion  of  the  using 
programmer  (Bothe  and  others,  1989:62). 

PCC  uses  a  pipelined,  four-pass  design  to  perform 
translations.  One  pass  is  for  lexical  and  syntactic  analy¬ 
sis.  Another  pass  analyzes  the  semantics  of  the  Pascal 
source.  A  third  pass  generates  the  C  program.  The  final 
pass  is  uses  to  beautify  the  output  C  program.  Using  this 
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architecture,  PCC  can  translate  extremely  large  programs 
because  it  limits  the  size  of  each  pass  to  40  KBytes  and  the 
symbol  table  is  only  maintained  as  long  as  the  variables  are 
in  a  current  scope  --  like  a  one-pass  compiler  (Bothe  and 
others,  1989:63). 

Three  methods  exist  to  handle  dialects  of  Pascal.  The 
first  is  for  the  programmer  to  manually  convert  the  source 
program  into  standard  Pascal  which  is  accepted  by  PCC. 
Second,  a  nonstandard  Pascal  program  can  be  partly  translat¬ 
ed  by  PCC  (about  90  percent)  and  the  remainder  done  by  hand. 
Thirdly,  the  PCC  itself  may  be  modified  to  handle  the  non¬ 
standard  constructs  of  the  dialect  (Bothe  and  others, 
1989:63-64)  . 

Portability  of  PCC  was  maintained  first  by  using  the  C 
programming  language  and  second  by  avoiding  language  fea¬ 
tures  not  supported  by  some  of  the  existing  C  compilers 
(Bothe  and  others,  1989:64). 

Deriving  the  requirements  for  PCC  based  on  the  uses  of 
translating  systems  provided  insight  into  the  need  for 
proper  domain  analysis  prior  ro  implementing  a  project. 

This  principle  will  be  applied  in  Chapter  3  of  this  thesis. 

2.5.3  Small  Euclid  to  Pascal.  The  Small  Euclid  to 
Pascal  translator  was  developed  to  translate  a  medium  size 
application  (an  assembler) .  Understanding  the  application 
and  recoding  it  in  Pascal  would  have  been  an  error  prone 
activity.  Developing  the  translator  ensured  a  correct 
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translation  and  provided  a  tool  for  future  use  (Pintelas  and 
others,  1989:93). 

Because  it  is  easier  to  translate  to  a  related  lan¬ 
guage,  Pascal  was  chosen  as  the  target  language  since  Euclid 
development  was  based  on  Pascal.  Also,  the  popularity  of 
Pascal  means  more  machines  can  process  the  resulting  program 
code  (Pintelas  and  others,  1989:93). 

To  avoid  portability  problems,  the  translator  was 
written  in  C  and  designed  to  translate  to  a  core  of  Pascal 
(those  features  of  Pascal  available  on  all  or  most 
machines) .  Due  to  this  choice,  some  drawbacks  were  unavoid¬ 
able  .  One  drawback  is  the  extended  use  of  goto  statements 
in  the  translated  code.  Another  drawback  is  that  new  logi¬ 
cal  variables  are  required  in  the  target  code.  Further,  the 
descriptive  Euclid  identifiers  must  be  somehow  shortened  to 
a  maximum  of  eight  characters.  Due  to  these  drawbacks,  the 
translated  code  is  not  very  readable  or  well  structured. 
However,  since  the  goal  of  the  translation  process  was  to 
produce  compilable  code  and  not  so  much  for  human  interven¬ 
tion,  this  is  not  too  much  of  a  problem.  Should  humans  need 
to  use  the  output,  a  pretty  printer  program  could  improve 
the  Pascal  text  (Pintelas  and  others,  1989:93). 

The  translator  expects  semantically  correct  Small 
Euclid  programs.  It  does  a  complete  syntax  check,  but  not  a 
exhaustive  semantic  check  on  the  source  (Pintelas  and  oth¬ 
ers  ,  1989 : 94 ) . 
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One  of  the  differences  between  Small  Euclid  and  Pascal 


which  the  translator  must  address  is  the  declaration  of 
constants,  variables,  types,  and  procedures.  In  a  Small 
Euclid  program,  these  may  be  declared  in  any  order.  Howev¬ 
er,  Pascal  has  a  fixed  order  of  declarations  for  a  program 
(Pintelas  and  others,  1989:94). 

Another  difference  is  the  scoping  of  variables.  In 
Small  Euclid,  an  import  list  is  used  to  identify  which 
variables  are  visible  to  an  internal  procedure.  Small 
Euclid  also  provides  a  constant,  type,  variable,  procedure, 
or  function  to  be  declared  as  pervasive  and  then  it  does  not 
need  to  be  included  in  an  access  list  to  be  visible.  In 
Pascal,  all  variables  in  the  scope  of  the  procedure  are 
visible  and  are  therefore  equivalent  to  the  Small  Euclid 
pervasive  declarations  (Pintelas  and  others,  1989:94). 

Various  statements  of  the  two  languages  differ.  The  IF 
statements  are  different.  Pascal  uses  an  IF-THEN-ELSE 
structure  where  Small  Euclid  uses  an  IF-THEN- (ELSIF-THEN) - 
ELSE-ENDIF  structure.  The  loop  constructs  of  Pascal  are 
replaced  in  Small  Euclid  with  a  more  general  loop  statement. 
Unlike  Pascal,  the  Small  Euclid  CASE  statement  provides  an 
OTHERWISE  clause  (Pintelas  and  others,  1989:95). 

Some  of  the  other  differences  have  to  do  with  declara¬ 
tions.  In  Pascal,  local  declarations  come  right  after  the 
procedure  header,  but  in  Small  Euclid  they  come  after  the 
first  BEGIN.  Also,  name  equivalence  is  used  for  type  check- 


2.19 


ing  in  Pascal  (types  of  items  are  equal  only  if  the  type 
name  matches)  whereas  Small  Euclid  uses  the  harder  to  check 
structural  equivalence  for  types  (types  of  items  are  equal 
if  they  have  the  same  structure  and  their  description  values 
are  equal)  (Pintelas  and  others,  1989:95). 

The  translator  was  designed  to  perform  the  translation 
in  three  passes.  The  first  pass  simply  converted  a  multiple 
file  program  into  a  single  file  for  translation.  The  second 
pass  was  used  for  textual  processes  such  as  the  removal  of 
white  space,  removal  of  comments,  and  conversion  of  upper¬ 
case  characters  to  lower  case  characters.  The  translator 
developers  decided  to  remove  comments  because  leaving  them 
in  might  be  confusing  as  the  resultant  Pascal  program  was  a 
drastic  change  from  the  input  Small  Euclid  code.  The  third 
pass  was  the  most  significant  and  consisted  of  three  basic 
modules:  the  lexical  analyzer,  the  symbol  table,  and  the 
syntax  analyzer  (Pintelas  and  others,  1989:98-99). 

The  tools  LEX  and  YACC  were  used  extensively  and  a 
large  number  of  action  routines.  The  lexical  analyzer's 
basic  job  was  to  deliver  tokens  to  the  syntax  analyzer. 

Since  assertion  statements  were  turned  into  comments,  the 
lexical  analyzer  handled  all  assertion  statements  by  deliv¬ 
ering  the  comments  to  the  current  output  file  (Pintelas  and 
others,  1989:99). 

The  symbol  table  was  needed  for  several  important 
reasons,  some  of  which  follow.  Declaration  names  needed  to 
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be  transformed  before  being  transferred  to  the  Pascal  output 
file.  Some  new  names  had  to  be  created  due  to  the  length 
restrictions  imposed  by  Pascal.  Some  structure  had  to  store 
all  information  regarding  a  name  for  use  during  the  transla¬ 
tion  process.  Finally,  declaration  names  had  to  be  collect¬ 
ed  before  being  sent  to  the  Pascal  output  (Pintelas  and 
others,  1989:99)  . 

The  syntax  analyzer  initialized  and  managed  the  symbol 
table  task.  It  also  called  the  lexical  analyzer  when  tokens 
were  needed.  It  managed  all  temporary  files.  Finally,  it 
checked  the  input  Small  Euclid  and  output  Pascal  program  for 
syntactic  correctness.  Since  the  translator  expected  a 
syntactically  correct  input  Small  Euclid  program,  it  would 
attempt  translation  until  a  syntax  error  was  recognized  and 
then  terminate  (Pintelas  and  others,  1989:100). 

The  building  of  the  Small  Euclid  to  Pascal  translator 
was  a  significant  effort  that  was  eased  by  the  use  of  LEX 
and  YACC  tools.  Yet,  the  project  took  ten  man  months  and 
produced  over  3,000  lines  of  source  code  (Pintelas  and 
others,  1989:100). 

2.5.4  Lisp  to  Fortran .  TAMPR  was  a  program  transfor¬ 
mation  system  written  in  applicative  LISP  which  was  trans¬ 
lated  into  Fortran.  The  method  used  was  to  analyze  the 
required  transformation  and  break  it  into  smaller  steps. 

The  idea  is  to  preserve  the  correctness  of  the  program 
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through  a  sequence  of  relatively  small  alterations  (Boyle, 
1984:291) . 

The  first  idea  was  to  transform  the  LISP  program  to 
Fortran  in  two  stages.  The  first  stage  was  to  convert  LISP 
code  to  Recursive  Fortran.  The  second  stage  would  then 
convert  the  Recursive  Fortran  into  an  executable  form  of 
Fortran,  either  Fortran  66  or  Fortran  77.  In  the  final 
design,  about  20  levels  of  transformations  were  used  (Boyle, 
1984:292)  . 

The  first  levels  of  the  transformer  converted  the  input 
LISP  into  a  form  that  could  be  translated  into  Fortran.  The 
last  of  these  steps  resulted  in  a  form  of  LISP  that  had 
nontrivial  functions  evaluated  in  the  argument  part  of 
lambda  expressions.  This  form  was  then  translatable  into 
Recursive  Fortran  statements  with  no  more  than  one  recursive 
call.  The  latter  steps  involve  recursion  removal  from  the 
Fortran  code  (Boyle,  1984:292,294). 

An  interesting  benefit  of  using  small  transformation 
steps  to  translate  programs  is  that  intermediate  results  are 
available  for  optimization.  In  this  way,  correct  and 
optimized  code  is  used  for  each  input  to  the  next  transfor¬ 
mation  step  (Boyle,  1984:294-295). 

The  transformation  of  TAMPR  from  LISP  into  Fortran  was 
accomplished  in  a  totally  automated  fashion  (no  manual 
intervention),  and  the  resultant  Fortran  program  ran  25 
percent  faster  than  the  original  LISP  program  on  the  same 
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platform.  This  example  showed  that  a  practical  approach  to 
synthesizing  programs  is  to  use  program  transformation 
(Boyle,  1984:296-297). 

2.5.5  Ada  to  Pascal  and  Pascal  to  Ada.  A  method  of 
translation  was  described  that  allows  bidirectional  transla¬ 
tion  between  two  languages.  In  the  case  of  the  article,  Ada 
and  Pascal  were  used.  The  translation  method  used  is  to 
define  a  subset  of  each  language  for  which  there  exists  a 
direct  translation  into  the  subset  of  the  other  language. 
PascalA  and  AdaP  were  defined  and  their  semantic  concepts 
map  to  the  other's  in  a  simple  one-to-one  manner.  In  this 
sense,  PascalA  and  AdaP  represent  two  equivalent  forms  of  a 
new  language,  PascAda  (Albrecht  and  others,  1980:183-184). 

Using  the  similar  sublanguage  approach,  the  sublan¬ 
guages  correspond  in  three  ways.  First,  program  semantics 
are  preserved.  Second,  the  form  and  structure  are  pre¬ 
served.  Third,  local  transformations  result  (Albrecht  and 
others,  1980:184). 

The  first  step  of  sublanguage  definition  is  to  define 
an  extended  sublanguage  of  the  original  language  for  which 
all  constructs  are  mappable  to  the  other  original  language. 
Obviously,  this  extended  sublanguage  should  be  as  rich  as 
possible.  Then  determine  the  mappings  between  this  extended 
sublanguage  and  the  sublanguage  which  is  the  syntactic 
equivalent  of  the  other  original  language's  sublanguage 
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(Albrecht  and  others,  1980:184).  Figure  2-1  provides  an 
example  to  clarify  this  concept. 


Consider  source -to -source  translation  between  Pascal 
and  Ada  depicted  in  Figure  2-1.  Given  that  not  all  Pascal 
constructs  may  map  to  Ada,  the  extended  subset  of  Pascal 
called  PascalAE  for  which  all  constructs  are  mappable  to  Ada 
is  defined.  Next,  a  similar  extended  subset  for  Ada  called 
AdaPE  is  defined.  Now,  these  extended  subset  languages  are 
mappable  to  the  sublanguages  PascalA  and  AdaP  (respectively) 
which  are  easily  translated  between  because  they  are  the  two 
syntactic  forms  of  the  PascAda  language  (Albrecht  and  oth¬ 
ers,  1980:184) . 

The  structure  of  the  PascAda  system  consists  of  seven 
routines  which  provide  eight  logical  units .  Four  units 
translate  the  Pascal  side  and  the  other  four  units  translate 
the  Ada  side.  The  unit  PascalToTree  translates  Pascal 
source  into  a  nonstandard  PascalAE  tree  structure,  producing 
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error  messages  if  language  constructs  occur  for  which  there 
is  not  a  PascalAE  representation.  The  unit  PascalAEToA  does 
a  tree  to  tree  transformation  to  convert  PascalAE  into 
PascalA  syntax.  A  unit  called  PascalACheck  then  ensures  the 
resultant  tree  contains  only  semantically  correct  PascalA 
constructs,  and  if  the  tree  is  in  a  nonstandard  form,  it  is 
converted  to  a  standard  tree.  The  TreeToPascal  unit  pro¬ 
duces  Pascal  code  from  a  standard  PascalA  tree.  Similarly 
for  Ada,  the  AdaToTree  unit  constructs  a  nonstandard  tree 
from  Ada  source  code.  The  AdaPEToP  unit  uses  a  tree-to-tree 
transformation  to  convert  AdaPE  constructs  into  AdaP  syntax. 
The  AdaPCheck  unit  then  checks  that  only  semantically  cor¬ 
rect  constructs  are  in  the  tree.  Finally,  the  TreeToAda 
unit  uses  a  standard  AdaP  tree  to  produce  Ada  code  (Albrecht 
and  others,  1980:188). 

2.6  Summary 

This  chapter  has  reviewed  the  literature  to  provide  a 
basis  of  knowledge  for  further  work  toward  development  of 
the  Style-V  translator.  Section  2.1  covered  the  fundamen¬ 
tals  of  computer  language  translation.  Lexical  analysis 
which  is  part  of  every  translation  task  was  reviewed  in 
Section  2.2.  The  parsing  task  and  current  work  on  tech¬ 
niques  comprised  Section  2.3.  The  need  to  ensure  language 
grammars  are  processed  without  ambiguity  was  covered  in 
Section  2.4,  and  methods  were  described  for  disambiguating  a 
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grammar.  Finally,  Section  2.5  provided  examples  of  transla¬ 
tors  which  have  been  developed  and  described  some  of  the 
techniques  used. 

iiie  information  in  this  chapter  provides  the  foundation 
for  the  research  to  continue  into  the  requirements  defini¬ 
tion  phase  for  the  Style -V  translator  --  the  subject  of 
Chapter  3  of  this  thesis. 
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ill.  Requirements  Analysis 


3.0  Introduction 

This  chapter  details  the  requirements  analysis  process 
used  to  develop  the  Style -V  translator  for  translating 
standard  IEEE  VHDL  into  a  specially  styled  VHDL. 

To  design  a  successful  program,  the  developer  must 
understand  the  problem  at  hand.  This  requires  a  careful 
study  of  all  aspects  of  the  problem  --  analysis.  The 
Webster's  II  dictionary  defines  analysis  as  "separation  of 
an  intellectual  or  substantial  whole  into  its  constituent 
parts  for  individual  study"  (Webster's,  1984:104).  In  the 
context  of  a  computer  system,  the  developer  must  define  what 
is  to  be  done,  by  whom,  when,  and  how. 

For  the  purposes  of  this  thesis,  analysis  is  the  proc¬ 
ess  of  specifying  the  parts  of  the  Style-V  Translator  sys¬ 
tem,  how  they  interact,  and  what  they  produce.  The  results 
of  analysis  should  completely  specify  the  behavior  of  the 
software  system  (Davis,  1990:7,17).  The  parts  of  the  system 
are  then  categorized  as  hardware,  software,  and  peopleware. 
Hardware  consists  of  the  computers  and  peripheral  equipment 
on  which  the  software  programs  and  data  are  processed.  The 
software  component  consists  of  programs  and  data  needed  to 
provide  the  functionality  desired  of  the  system.  Finally, 
the  peopleware  component  consists  of  the  users  of  the  sys¬ 
tem. 
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This  chapter  will  review  the  methods  available  for 
conducting  systems  analysis,  describe  in  detail  the  method 
chosen,  provide  a  domain  analysis  of  the  problem  domain,  use 
the  domain  analysis  results  to  analyze  the  Style-V  system, 
and  end  with  a  summary  of  the  analysis  effort. 

3.1  Review  of  Methods 

As  with  most  development  processes  in  computer  science, 
no  one  method  of  analysis  has  been  adopted  as  the  standard 
best  way.  Instead,  a  plethora  of  methods  exists,  and  a 
developer  must  choose  a  method  (or  combination  of  methods) 
that  suits  both  the  type  of  problem  at  hand  and  the 
developer's  personal  preferences,  since  more  than  one  method 
may  be  equally  valid. 

All  current  methods  of  analysis  can  be  classified  as 
either  functional  or  object-oriented  analysis.  In  function¬ 
al  analysis,  the  problem  is  analyzed  to  determine  the  func¬ 
tions  and  data  needed  to  solve  it.  Functional  analysis 
considers  the  functions  and  their  associated  data  or  control 
flow.  Object-oriented  analysis  takes  a  somewhat  different 
approach  by  determining  the  objects  which  exist  in  the 
problem  space  (application  domain) .  The  services  provided 
by  and  required  by  the  objects  are  identified.  Also,  the 
attributes  of  objects  and  their  relationships  are  identified 
(Davis,  1990 : 46 ) . 
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Several  notations  for  analysis  are  coiranon.  Data  flow 
diagrams  (DFD)  were  popular  for  problem  solving  even  before 
the  time  of  computers,  and  they  are  quite  applicable  to 
computational  problem  solving.  A  DFD  represents  data  flow 
(by  labeled  directed  arrows)  between  transformation  centers 
(represented  by  bubbles),  and  sources  and  destinations  of 
data  called  terminators  (Davis,  1990:57). 

In  addition  to  DFDs,  control  flow  diagrams  (CFDs), 

Mealy  or  Moore  machine  representations,  process  activation 
tables,  and  requirements  dictionaries  are  further  analysis 
tools  and  are  quite  helpful  when  analyzing  real-time  systems 
(Davis,  1990:60-61). 

A  companion  for  DFDs  is  the  data  dictionary  (DD) .  The 
DD  stores  information  on  data  items  such  as  name,  aliases, 
descriptions,  relations,  values,  data  flows,  and  structure 
definitions  (Davis,  1990:62). 

Another  notation  is  the  entity-relationship  diagram. 
Using  this  notation,  a  designer  identifies  the  entities  in 
the  problem  placing  them  in  rectangles.  Relations  are 
identified  in  diamonds  and  placed  between  the  entities  on 
the  diagram.  Entity  attributes  are  noted  in  circles  at¬ 
tached  to  the  entity's  rectangle. 

In  the  object  oriented  world,  Peter  Goad  developed  a 
diagram  that  combines  the  advantages  of  DFDs  and  ER  dia¬ 
grams.  His  GOAD  objects  contain  attributes,  suffered  opera¬ 
tions,  and  required  operations.  They  also  have  two  types  of 
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structural  relationships:  classification  and  assembly. 
Classification  relations  show  a  class  (or  type)  of  an  object 
(in_patient  and  out_patient  are  of  class  patient).  Assembly 
relations  show  a  "part-of"  relation  between  objects  (heart 
and  liver  objects  are  parts  of  a  person  object)  (Davis, 
1990:63-69)  . 

One  technique  used  by  analysts  to  gain  an  understanding 
of  a  problem  domain  is  Domain  Analysis  (DA) .  The  general 
class  of  problems  in  which  the  current  problem  of  interest 
is  a  part  is  analyzed.  Then,  the  processes  required  by  any 
system  which  would  operate  in  the  problem  domain  are  identi¬ 
fied.  Finally,  the  system  is  related  to  the  inputs,  out¬ 
puts,  and  processes  pertinent  to  the  system.  Section  3,3 
provides  an  example  of  this  process. 

Davis  describes  eight  methods  of  analysis  (Davis, 
1990:71-100).  Each  of  the  methods  uses  a  combination  from 
the  notations  described  in  this  section  or  possibly  some 
method  specific  notations.  The  eight  methods  Davis  de¬ 
scribed  are: 

1.  Listing  All  Inputs  and  Outputs. 

2.  Listing  Major  Functions. 

3.  Structured  Requirements  Definition  (SRD) . 

4.  Structured  Analysis  and  Design  Technique  (SADT) . 

5.  Structured  Analysis  and  System  Specification 

(SASS) . 

6.  Modern  Structured  Analysis  (MSA). 
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7 .  Problem  Statement  Language  /  Problem  Statement 

Analyzer  (PSL/PSA)™. 

8.  Object-Oriented  Problem  Analysis  (OOA) . 

3.2  Method  Chosen 

Domain  Analysis  (DA)  and  Modern  Structured  Analysis 
(MSA),  as  defined  by  Ward  and  Mellor,  were  chosen  for  this 
thesis  effort.  They  provide  a  logical  and  straightforward 
process  for  performing  system  analysis. 

Domain  analysis  helps  the  analyst  understand  the  class 
of  problems  at  hand  by  describing  the  parts  of  a  system. 

MSA  uses  the  parts  of  the  system  defined  in  DA  to  solve  a 
particular  problem  --  in  the  case  of  this  thesis  it  solves 
the  problem  of  translating  standard  VHDL  into  a  subset. 

Structured  Analysis  has  been  around  for  a  long  time. 
Modern  structured  analysis  has  evolved  from  a  great  wealth 
of  experience  and  ideas .  Davis  provides  a  summary  of  two 
methodologies,  that  of  Ward  and  Mellor  and  that  of  Yourdon 
(Davis,  1990:91). 

Briefly,  Ward  and  Mellor 's  method  consists  of  four  main 
activities.  The  first  step  is  to  identify  all  terminators 
to  the  system,  the  system,  and  all  data  flows;  in  other 
words,  define  the  system  context.  The  second  step  is  to 
create  a  narrative  event  list  which  defines  all  external 
events.  Third,  the  behavior  of  each  event  is  captured  as  a 
single-bubble  DFD.  Finally,  the  fourth  step  is  to 
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successively  group  (combine)  the  disjoint  EFDs  created  in 
step  three  into  more  abstract  models . 

Ward's  advice  for  grouping  Z/FDs  consists  of  minimizing 
interfaces,  identifying  control  hierarchies,  grouping  common 
responses,  grouping  processes  based  on  their  sharing  of 
data,  grouping  of  common  terminators,  and  grouping  so  ab¬ 
stract  groups  logically  have  different  names.  Yourdon 
suggests  to  simply  group  diagrams  sharing  common  data  and 
group  diagrams  which  can  hide  information  in  the  system. 

Yourdon 's  method  of  structured  analysis  is  to  define  a 
system  as  two  models:  behavioral  and  environmental;  these 
then  define  the  essential  model  of  .the  system.  The  models 
use  DFDs,  DDs,  ERDs,  and  process  specifications.  The  envi¬ 
ronmental  model  consists  of  a  statement  of  purpose  for  the 
system,  a  context  diagram  that  shows  the  system  and  objects 
external  to  it  and  any  interfaces,  and  a  list  of  the  events 
of  the  system.  The  behavioral  model  consists  of  a  complete 
set  of  DFDs  by  Ward's  method,  entity- relationship  diagrams 
of  all  objects  in  the  system  and  those  with  which  the  system 
interacts,  state  transition  diagrams  for  the  control  process 
behavior,  a  data  dictionary,  and  process  specifications  for 
the  lowest  level  processes . 

Modern  structured  analysis  does  not  require  the  use  of 
automated  programs  which  are  xequired  by  some  of  the  other 
methods  and  which  may  not  be  readily  available.  An  automat¬ 
ed  tool  to  create  DFDs  and  DDs  and  ensure  their  consistency 
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would  be  desirable,  but  any  graphics  package  can  suffice  for 
creating  modern  structured  analysis  drawings  and  any  text 
editor  or  word  processor  will  suffice  for  creating  related 
documentation . 

Another  benefit  of  modern  structured  analysis  is  how 
the  results  consist  of  well-defined  functional  entities. 
These  functional  entities  then  form  the  foundation  for  the 
functional  design  of  a  system. 

Obviously,  from  the  discussion  thus  far,  the  approach 
to  the  development  of  Style-V  is  functional  decomposition. 
The  original  observation  guiding  this  decision  was  that  few 
objects  exist  in  the  problem  space  --  mainly  only  input 
files,  the  Style-V  translator,  and  output  files.  In  Section 
3.3  the  parts  of  a  translator  are  defined.  Most  of  the  real 
work  (translation  tasks)  of  the  translator  is  done  by  one  of 
the  parts.  Therefore,  since  the  largest  part  of  the  trans¬ 
lator  would  be  functionally  defined,  even  in  an  object- 
oriented  approach,  a  functional  approach  to  analysis  was 
deemed  best. 

3.3  Domain  Analysis  of  Stvie-V 

The  analysis  of  Style-V  is  unlike  many  of  the  analysis 
techniques  described  by  Davis  and  reviewed  in  Section  3.2. 
Most  of  the  methods,  including  MSA,  start  by  defining  how  an 
organization  is  currently  doing  a  task  and  then  analyze  the 
task  performance  of  parts  of  the  organization.  With 
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Style-V,  no  organization  is  currently  doing  the  translation 
work  of  Style-V;  therefore,  some  other  method  was  required 
to  provide  a  starting  point  for  MSA.  Domain  analysis  pro¬ 
vides  a  way  to  gain  a  broad  understanding  of  a  problem  and  a 
place  to  start  the  analysis  process. 

The  translators  reviewed  in  Chapter  2  provide  a  basis 
for  determining  the  generic  components  of  a  translator.  By 
analyzing  how  those  translators  work,  it  was  determined  that 
a  translator  is  made  up  of  three  general  processes  --  lexi¬ 
cal,  syntactic,  and  semantic.  These  processes  operate  on  an 
external  input  to  produce  an  external  output  (input  and 
output  files). 

Lexical  analysis  is  the  process  of  determining  the 
tokens  of  an  input  file  to  pass  to  the  syntactic  or  semantic 
processes.  Generally  for  programming  languages,  the  tokens 
are  words,  delimiters,  and  operators.  In  some  cases,  the 
tokens  may  be  entire  strings  (such  as  comments)  if  this 
level  of  intelligence  is  coded  into  the  lexical  analyzer; 
otherwise,  syntactic  and  semantic  routines  process  complex 
tokens . 

Syntactic  analysis  determines  if  a  sequence  of  tokens 
is  grammatically  correct.  If  a  sequence  of  tokens  is  not 
allowed  by  the  rules  of  the  source  language,  a  correct 
translation  is  highly  unlikely  and  an  error  should  be  gener¬ 
ated.  Some  translators  do  not  include  a  syntactic  analyzer 
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(or  contain  a  very  simple  one)  because  the  input  is  assumed 
to  be  syntactically  correct.  This  is  the  approach  of 
Style-V. 

Style-V  is  not  meant  to  replace  a  VHDL  analyzer.  The 
input  files  to  Style-V  are  assumed  to  be  syntactically 
correct  VHDL,  since  translating  an  incorrect  (untried)  VHDL 
description  to  a  tool  such  as  JRS'  IDAS  does  not  make  sense. 
It  is  easy  to  see  the  old  computer  science  adage  "garbage 
in,  garbage  out"  applies  in  this  case. 

Semantic  processing  analyzes  the  sequence  of  tokens  of 
a  language  to  determine  the  meaning  of  the  input.  Meaning 
can  be  on  a  statement-by-statement  basis  for  some  transla¬ 
tion  tasks.  However,  for  other  translation  tasks,  a  more 
global  understanding  of  a  set  of  statements  is  required  for 
a  translator  to  be  able  to  generate  a  correct  translation. 
The  semantic  process  does  most  of  the  translation  work. 

Figure  3-1  provides  the  highest  level  pictorial  view  of 
the  concept  of  a  translator  system.  It  has  one  bubble 
representing  the  translator  system,  one  storage  symbol  for 
input  files,  and  one  storage  symbol  for  output  files. 

Figure  3-2  is  a  decomposition  of  the  translator  system  into 
its  constituent  parts;  the  lexical  analyzer,  the  syntactic 
analyzer,  and  the  semantic  analyzer.  Figures  3-3,  3-4,  and 
3-5  are  the  conceptual  descriptions  of  the  three  processes 
of  a  translator  system.  Now  that  the  domain  is  defined,  the 
next  step  is  to  analyze  the  problem  into  its  constituent 
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parts.  Then,  the  functions  necessary  to  implement  the 
subpart  can  be  defined  and  assigned  to  one  of  the  translator 
processes . 


Figure  3-1.  Style -V  Level  One  Concept  Map 


/ 


\ 
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Figure  3-2.  Decomposition  of  Translator  Concept 
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Domain  analysis  has  shown  that  lexical,  syntactic,  and 
semantic  analysis  are  essential  parts  of  a  translation 
system.  However,  since  the  input  to  Style-V  is  syntactical¬ 
ly  correct  VHDL,  Style-V  need  not  worry  about  checking 
syntax.  The  other  functions,  lexical  and  semantic  analysis, 
are  the  basis  for  how  Style-V  will  perform  the  translation 
task.  Any  major  function  of  Style-V  that  reads  input  and 
produces  output  must  perform  lexical  and  semantic  process¬ 
ing.  The  way  Style-V  will  do  this  is  described  in  Section 
3.5.  However,  before  a  description  of  how  the  translation 
will  be  done  is  possible,  an  analysis  of  the  problem  to 
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determine  what  must  be  translated  is  required,  and  this  is 
the  subject  of  Section  3.4. 

3.4  Problem  Analysis 

A  fundamental  truth  about  program  translation  is  that  a 
syntactically  and  semantically  correct  input  must  be  trans¬ 
lated  into  a  syntactically  and  semantically  correct  output. 
Since  translation  of  standard  VHDL  into  the  subset  defined 
for  the  JRS  IDAS  tool  has  not  been  done,  a  careful  defini¬ 
tion  of  the  differences  between  the  subset  and  the  standard 
was  imperative.  Without  knowing  what  is  in  the  standard 
which  is  not  allowed  in  the  subset,  creating  a  translator  to 
consistently  produce  an  output  which  contains  only  con¬ 
structs  allowed  in  the  subset  is  impossible. 

Section  3.4.1  provides  a  discussion  of  the  differences 
between  standard  VHDL  and  the  JRS  styled  subset  including  a 
possible  mapping  from  the  standard  to  the  subset.  Section 
3.4.2  describes  an  example  system  coded  in  JRS  styled  VHDL 
to  gain  an  understanding  of  the  requirements  and  limitations 
of  the  subset.  Section  3.4.3  is  a  discussion  of  the  lessons 
learned  from  the  example  system.  Finally,  Section  3.4.4  is 
a  discussion  of  the  limitations  imposed  by  using  the  subset 
of  VHDL  defined  by  the  JRS  style. 

3.4.1  Stylized  and  Standard  VHDL  Compared .  The  only 
document  which  provides  insight  into  what  is  allowed  for  the 
JRS  style  of  VHDL  required  for  IDAS  is  the  VHDL  Style  Guide 
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for  Ada  to  Microcode  Compiler  Retargeting  and  VHDL  Simula¬ 
tion  (VHDL  Style,  1989).  For  each  restricted  construct,  a 
mapping  from  the  standard  to  some  construct  or  group  of 
constructs  in  the  subset  must  be  possible  before  translation 
is  possible .  The  remainder  of  this  section  describes  the 
restrictions  imposed  by  JRS  on  VHDL  written  for  the  IDAS  and 
one  or  more  possible  mappings  from  standard  VHDL.  Figure  3- 
6  provides  an  abbreviated  description  of  the  mappings  any 
successful  translator  must  address. 

3 . 4 . 1 . 1  Type  Differences .  A  translator  for 
standard  VHDL  to  a  JRS  style  VHDL  must  address  several  type 
conversion  issues.  The  restrictions  imposed  by  the  JRS 
style  are  quite  severe.  A  careful  review  of  the  JRS  Style 
Guide  resulted  in  documentation  of  the  restrictions  and 
found  that  types  in  JRS  styled  VHDL  are  limited  to  the  fol¬ 
lowing  (VHDL  Style,  1989:4): 

a.  BIT  --a  binary  0  or  1, 

b.  BIT_VECTOR  --a  one-dimensioual  array  of  BIT, 

c.  ARRAY  of  BIT_VECTOR  --  a  one-dimensional  array 

of  BIT_VECTOR, 

d.  STATUS_TYPE  --a  special  enumerated  type. 

Since  standard  VHDL  allows  user  defined  types,  such  as 
enumerated  types  to  model  multilevel  logic,  some  mapping 
from  multilevel  logic  to  the  types  BIT  and  BIT_VECTOR  was 
required. 
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This  mapping  was  originally  thought  to  be  a  trivial 
matter  of  assigning  the  value  '0'  or  ' 1'  to  each  of  the  enu¬ 
merated  type  fields  to  derive  a  type  compatible  with  the 
type  BIT.  However,  a  careful  study  of  a  real-world  design, 
the  Floating  Point  Application  Specific  Processor  (FPASP) , 
which  uses  four- level  logic  showed  that  the  arbitrary 


Standard  or  User  Types  ==>  BIT  Types 


CASE  Statements  ==>  IF  Statements 

Machine  Specific  ==>  Machine  Specific 

Declarations  Scattered  Declarations  Packaged 

Modes  Buffer  and  Linkage  ==>  Mode  INOUT 

Allowed  Types  in  Generics  ==>  INTEGER,  TIME,  FLOAT, 

or  STRING  for  Generics 

Multiple  Concurrent  ==>  Single  PROCESS 
Statement  Architectures  Statement  Architectures 

Guards  and  Sensitivity  Lists  ==>  WAIT  Statements 

Tests  for  Data  Values  ==>  No  Tests  for  Data  Values 

Signal  Assign  Delay  in  ==>  No  Signal  Assign  Delay 
Structural  Architectures  in  Structural  Arch. 

WAIT  as  Signal  Delay  ==>  Signal  Assignment  with 
Method  "AFTER"  Clause  for  Delay 

User  Defined  Procedures  ==>  IDAS  Provided  Procedures 

Variables  or  Signals  for  ==>  Special  Status_Type  for 
Tracking  Status  Tracking  Status 


Component  Names  and  ==>  Component  Names  and 

Ports  Can  Differ  w/  Entity  Ports  Must  Match  Entity 


Figure  3-6.  Standard  VHDL  Mapped  to  JRS  Style  VHDL 
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assigning  of  the  value  '1'  or  '0'  to  the  levels  'X'  or  'Z' 
would  result  in  incorrect  behavior  of  the  procedures  defined 
for  the  design.  Consider  the  segment  of  code  from  the  FPASP 
design  in  Figure  3'7.  This  code  segment  looked  for  illegal 
values  in  the  input  early  in  the  procedure  and  if  found, 
exited  che  procedure  without  further  processing.  A  whole¬ 
sale  conversion  of  'Z'  and  'X'  to  either  '0'  or  ' 1'  would 
have  caused  this  procedure  to  never  execute  the  correct  code 
-  -  it  would  always  exit  at  the  example  FOR  loop . 


for  I  in  A_COPY' RANGE  loop 


I  if  (A_COPY(I)  =  'Z')  or  (A_C0PY(I)  =  'X')  then  | 

I  I 

1  return  (1  ns);  | 

I  1 

1  end  if;  I 

I  I 

I  end  loop;  | 

I  I 

\ . - . . . / 

Figure  3-7.  FPASP  Four-Level  Logic  Sample 

Another  considered  option  was  the  conversion  of  the 
bits  of  the  four-level  logic  into  two-bit  bit_vectors  (one¬ 
dimensional  arrays)  such  that  '0'  =  "00",  '1'  =  "01",  'X'  = 
"10",  and  'Z'  =  "11".  Then  a  four- level  logic  bit  vector 
such  as  "OIXZ"  would  appear  as  "  "00"  "01"  "10"  "11"  "  --  an 
array  of  bitvectors  (a  two-dimensional  array  of  bit) . 
Unfortunately,  the  JRS  MOVE  procedures  would  only  accept  the 
type  DATA  and  DATA_VECTOR  which  are  subtypes  of  BIT  and 
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BIT_VECTOR  respectively  (one -dimensional  arrays)  (VHDL 
Style,  1989:29,50).  The  JRS  MOVE  procedure  was  critical  to 
the  simulation  of  data  moving  through  a  design;  therefore, 
finding  a  data  representation  using  JRS  types  and  compatible 
with  the  JRS  MOVE  procedure  was  imperative. 

Given  the  JRS  MOVE  restriction,  the  answer  was  to 
convert  multilevel  logic  into  multiple-bit  single- level 
logic.  Then,  JRS'  MOVE  procedure  could  move  data  around  a 
design.  When  it  came  time  to  process  the  data  through 
another  JRS  procedure,  the  data  could  be  converted  to 
BIT_VECTOR  logic  (note:  since  only  BIT  logic  is  allowed  for 
JRS  procedures,  processing  JRS  procedures  other  than  MOVE 
requires  conversion  of  the  multibit  four-level  logic  to 
single-bit  two-level  logic,  thus  forcing  'X'  and  'Z'  to 
either  '0'  or  '1').  Upon  exiting  JRS  procedures,  the 
BIT_VECTOR  could  be  again  converted  to  multibit  four- level 
logic  where  each  bit  is  now  "00"  or  "01".  A  manual  review 
of  this  method  showed  it  practicable  and  a  hand  translation 
of  the  extensive  FPASP  type  definitions  demonstrated  its 
feasibility . 

A  second  type  restrictions  imposed  by  JRS  was  that 
status  of  the  model  would  be  tracked  using  a  special  enumer¬ 
ated  type  called  a  STATUS_TYPE  (VHDL  Style,  1989:18-20). 

This  is  a  device  independent  representation  of  status 
values .  JRS  IDAS  provided  functions  to  map  between  this 
STATUSTYPE  and  a  STATUS_VECTOR  which  is  a  machine  dependent 
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bit_vector  used  to  track  the  status  of  a  certain  machine. 

The  problem  is  that  most  status  tracking  in  real  machine 
designs  is  to  use  either  bits  or  bit_vectors  (in  the  logic 
scheme  of  the  design)  to  pass  status  values. 

Therefore,  a  method  was  required  to  convert  status 
represented  as  bit  or  bit_vector  to  STATUS_TYPE  required  by 
JRS  IDAS  procedures  and  back  again  to  bit  or  bit_vector  for 
movement  through  the  design.  Fortunately,  the  JRS  IDAS 
provision  of  the  MAP_STATUS  function  to  convert  between 
STATUS_TYPE  and  STATUS_VECTOR  (which  is  a  bit_vector  repre¬ 
sentation)  provides  the  first  step  in  solving  this  problem 
(VHDL  Style,  1989:18-20).  It  is  then  a  simple  matter  to  map 
a  field  of  the  STATUS_VECTOR  to  a  value  for  a  bit, 
bit_vector  variable,  or  signal  representing  status  in  a  de¬ 
sign.  Using  MAP_STATUS,  the  other  procedures  for  processing 
types,  and  a  simple  procedure  to  convert  STATUS_VECTOR  to  a 
variable  or  signal  solves  the  status  mapping  problem. 

However,  a  far  greater  problem  is  how  to  determine  if  a 
variable,  port,  or  signal  represents  a  field  dedicated  to 
tracking  status.  The  analysis  of  this  problem  did  not 
reveal  any  automated  way  to  accomplish  this  task.  Using 
standard  VHDL,  a  designer  can  name  variables,  ports,  and 
signals  with  any  legal  identifier  for  the  language  and  no 
standard  convention  exists  (for  example,  signal  GEZRO  : 
DESIGN_BIT;  --  a  status  of  greater  than  or  equal  to  zero). 
Given  this  fact,  human  intervention  will  be  necessary  to 


3.18 


determine  which  variables,  ports,  and  signals  represent 
status  in  a  design. 

A  third  restriction  on  types  has  to  do  with  the  modes 
allowed.  The  JRS  style  of  VHDL  does  not  allow  the  modes 
BUFFER  and  LINKAGE  (VHDL  Style,  1989:8).  After  a  careful 
review  of  the  modes  BUFFER  and  LINKAGE  in  the  VHDL  Language 
Reference  Manual  (IEEE  Standard  VHDL,  1988:4.10),  the  analy¬ 
sis  determined  that  the  mode  INOUT  can  be  substituted  for 
modes  BUFFER  or  LINKAGE.  This  may  seem  incorrect  at  first 
since  the  mode  INOUT  allows  more  operations  than  the  modes 
BUFFER  or  LINKAGE.  However,  remember  that  the  translation 
is  for  syntactically  and  semantically  correct  VHDL  input, 
since  Style -V  expects  an  input  of  a  design  that  works 
through  VHDL  the  way  the  designer  intended.  Therefore, 
conversion  to  a  more  general  mode  for  the  purposes  of  input 
to  a  special  tool  (in  this  case,  JRS  IDAS)  should  not  cause 
problems . 

A  fourth  restriction  on  types  is  the  limited  number  of 
types  allowed  in  GENERIC  statements.  JRS  IDAS  limits  the 
variables  of  generics  to  INTEGER,  TIME,  STRING,  or  FLOAT 
types  (VHDL  Style,  1989:9).  This  disallows  user  defined 
types  or  other  VHDL  defined  types  such  as  POSITIVE.  The 
translator  must  convert  more  restrictive  VHDL  types  to  a 
more  general,  allowed  type.  One  example  would  be  to  convert 
any  generic  variable  with  a  type  POSITIVE  to  the  type  INTE¬ 
GER.  Another  consideration  is  user  defined  types.  If  a 
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base  type  of  the  user  defined  type  is  one  of  the  allowed 
types  or  can  be  converted  to  one  as  explained  above,  change 
the  user -defined  type  to  that  base  type.  Otherwise,  if  the 
translator  cannot  convert  a  disallowed  type  to  an  allowed 
type,  manual  intervention  is  required  and  redesign  may  be 
necessary.  An  example  of  a  case  requiring  manual  interven¬ 
tion  is  a  type  resolving  to  an  enumerated  type  not  allowed 
by  IDAS  styled  VHDL. 

3 . 4 . 1 ■ 2  Declaration  Differences .  The  length  of 
time  required  for  one  instruction  fetch  cycle  must  be  de¬ 
fined  as  a  constant  in  the  package  Machine_Declarati ons  with 
the  name  CYCLE_LENGTH  (VHDL  Style,  1989:6).  This  "clock 
cycle"  is  normally  defined  in  the  test  bench  for  a  design  or 
through  a  generic  in  the  highest  level  architecture  under 
the  test  bench.  The  main  issue  is  how  to  detect  it  for 
definition  in  Machine_Declarations  --no  standard  naming 
convention  exists  for  the  clock  period  or  cycle  time. 

Again,  manual  intervention  is  necessary  to  identify  this 
value,  unless  only  one  variable  of  type  CLOCK  is  defined. 

Another  difference  between  standard  VHDL  and  the  JRS 
IDAS  styled  VHDL  is  the  definition  of  arrays  of  BIT_VECTOR 
which  are  machine  specific.  These  machine  specific  declara¬ 
tions  must  be  located  in  package  MACHINE_DECLARATIONS  (VHDL 
Style,  1989:6).  Therefore,  any  declaration  in  any  file  of 
the  design  which  has  a  type  that  does  not  map  to  the  type 
definitions  in  the  JRS  IDAS  provided  package  DATATYPES  must 
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be  moved  to  package  MACHINE_DECLAiyVTIONS .  This  means  pack¬ 
age  MACHINE_DECLARATIONS  must  be  included  in  a  USE  clause  in 
all  files  with  packages,  entities,  or  architectures  which 
use  a  type  defined  in  MACHINE_DECLARATIONS . 

Additionally,  all  declarations  of  bus  subtypes  and 
their  associated  resolution  functions  must  be  defined  in 
package  MACHINE_DECLARATIONS  (VHDL  Style,  1989:6).  These 
must  be  moved  to  MACHINE_DECLARATIONS  in  the  same  manner  as 
described  for  moving  machine  specific  data  type  definitions. 

A  fourth  problem  is  that  names  used  in  components  must 
match  the  design  entity  for  which  they  are  defined.  Addi¬ 
tionally,  component  ports  must  be  exactly  the  same  as  the 
design  entity  ports  (VHDL  Style,  1989:22,24).  In  standard 
VHDL,  neither  of  these  restrictions  apply.  To  stylize 
component  ports,  it  will  be  necessary  to  maintain  a  table  of 
entity  declarations  with  all  port  definitions.  Then,  when 
processing  component  declarations,  their  port  list  can  be 
compared  to  the  entity  port  list  and  adjustments  made. 

Ports  of  entities  not  used  in  components  can  be  added  to  the 
components  with  dummy  variables  or  signals.  The  actual 
design  should  still  work  if  it  worked  before  the  transla¬ 
tion  . 

3 . 4 . 1 . 3  Structural  Differences .  A  major 
difference  between  JRS  IDAS  styled  VHDL  and  standard  VHDL  is 
the  limitation  of  only  one  concurrent  statement  (a  process 
statement)  for  any  architecture  (VHDL  Style,  1989:11).  At 
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first  glance,  this  appears  to  be  a  monumental  problem  as 
VHDL  allows  any  combination  of  block  and  process  statements 
within  an  architecture  to  model  parallel  activities .  Com¬ 
bining  all  these  concurrent  statements  into  one  process 
would  destroy  the  concurrent  model.  The  answer  lies  in 
creating  several  single-process  architectures  as  subarchi¬ 
tectures  to  a  new  upper  level  architecture  (with  the  name  of 
the  original  multiprocess  architecture)  which  instantiates 
these  new  "component"  architectures.  This  process  is  de¬ 
scribed  in  detail  in  Section  3. 5. 3. 4. 

A  second  structural  issue  is  the  prohibition  in  JRS 
IDAS  styled  VHDL  for  sensitivity  lists  for  a  process  (VHDL 
Style,  1989:12).  Instead,  when  a  block  guard  or  process 
sensitivity  list  is  recognized,  collect  the  information  and 
after  the  process  BEGIN,  insert  a  VHDL  WAIT  statement  with 
an  UNTIL  clause  using  the  guard  condition  and  an  ON  clause 
using  the  signals  of  the  sensitivity  list.  This  effectively 
causes  the  process  to  wait  until  the  guard  condition  is  true 
and  one  of  the  inputs  has  changed  before  the  process  begins 
--  just  like  a  sensitivity  list.  The  UNTIL  clause  will  be 
added  to  the  WAIT  statement  for  each  process  that  was  part 
of  the  block. 

Thirdly,  the  placement  of  the  wait  for  a  behavioral  IF 
is  more  restricted  in  JRS  styled  VHDL  than  in  standard  VHDL. 
Any  delay  for  the  result  of  the  behavior  is  modeled  as  an 
AFTER  clause  in  a  signal  assignment  statement  following  the 
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behavioral  IF  (VHDL  Style,  1989:14,16).  When  a  WAIT  state¬ 
ment  precedes  an  IF  or  CASE  structure  or  a  signal  assignment 
statement,  if  it  is  not  the  first  WAIT  of  the  process,  then 
the  time  should  be  saved  and  placed  in  an  AFTER  clause  in 
the  appropriate  signal  assignment  statements. 

A  final  structural  issue  is  that  a  structural  architec¬ 
ture  statement  part  may  include  only  component  instantiation 
statements  and  simple  signal  assignment  statements  without 
delay.  If  delay  is  required,  the  behavior  mu'^t  be  modeled 
by  connecting  the  involved  signals  to  a  behavioral  design 
entity  with  a  MOVE  that  has  the  required  delay  (VHDL  Style, 
1989:24) . 

3 . 4 ■ 1 . 4  Statement  Differences .  Several  differ¬ 
ences  in  the  statement  composition  or  format  exist  between 
JRS  IDAS  style  VHDL  and  standard  VHDL.  The  first  is  the 
fact  that  the  behaviors  of  JRS  styled  VHDL  are  represented 
in  IF  statements  (VHDL  Style,  1989:11,13).  Standard  VHDL 
allows  the  more  versatile  CASE  statement,  so  a  CASE  to  IF 
conversion  is  required.  The  mapping  of  CASE  to  IF  state¬ 
ments  entails  recognizing  the  CASE  statement,  identifying 
the  conditional  variable,  and  processing  the  WHEN  clauses 
into  the  appropriate  clauses  of  the  IF-THEN-ELSIF-ELSE 
structure . 

A  second  statement  difference  between  standard  VHDL  and 
JRS  styled  VHDL  concerns  tests  for  value  in  the  guard  of  a 
behavioral  IF  statement.  In  JRS  styled  VHDL,  the  guard  can 
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only  contain  tests  for  phases  of  the  system  clock  and  micro - 
word  fields,  clock  tests  must  come  before  microword  tests, 
and  no  test  for  the  value  of  a  data  path  are  allowed  (VHDL 
Style,  1989:14).  Since  none  of  these  restrictions  apply  in 
standard  VHDL,  whenever  an  IF  is  encountered,  the  guard  must 
be  analyzed  and  reorganized  as  needed.  Also,  since  no  test 
of  a  data  line  is  allowed,  a  startup  input  defining  the  name 
of  the  control  word  and  all  clocks  will  be  required  for  the 
translator  to  be  able  to  ensure  no  data  path  test  is  at¬ 
tempted.  If  a  data  path  test  is  attempted,  the  translator 
could  optionally  print  a  warning  message  and  continue  proc¬ 
essing,  stop  for  manual  intervention,  or  report  an  error  and 
terminate  processing. 

A  final  statement  difference  between  standard  VHDL  and 
JRS  styled  VHDL  is  the  requirement  for  procedure  parameters 
of  mode  OUT  or  INOUT  to  be  variables  (VHDL  Style,  1989:15). 
If  mode  OUT  or  INOUT  parameters  are  not  variables,  the 
translator  must  insert  variable  declarations  of  the  appro¬ 
priate  type  in  the  process  containing  the  procedure  and  use 
them  in  the  procedure  call.  Additionally,  the  procedure 
call  must  be  followed  by  a  signal  assignment  statement  for 
each  variable  reassigning  the  value  of  the  variable  to  the 
appropriate  signal. 

3 . 4 . 1 . 5  Other  Differences .  Several  differences 
between  JRS  styled  VHDL  and  the  standard  do  not  fit  into  any 
of  the  aforementioned  categories .  Ono  concerns  the  JRS  IDAS 
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code  generator,  since  it  does  not  recognize  or  understand 
behaviors  other  than  those  provided  with  the  IDAS  (VHDL 
Style,  1989:18).  This  means  as  many  procedures  as  possible 
of  the  input  design  should  be  converted  to  JRS  IDAS  proce¬ 
dures.  The  implications  of  this  requirement  to  convert  any 
given  function  of  a  design  to  an  "equivalent"  function  in 
another  library  will  be  covered  in  Section  3.4.4. 

Another  issue  is  the  handling  of  tristate  busses . 
According  to  the  JRS  VHDL  Style  Guide,  all  devices  driving  a 
tristate  bus  should  be  controlled  by  one  field  of  the  micro - 
word  (VHDL  Style,  1989:25).  However,  if  the  type  conversion 
procedure  described  in  Section  3. 4. 1.1  works  as  designed, 
the  procedures  of  the  original  design  which  operated  on 
tristate  values  could  be  converted  and  still  operate  as 
before  --  the  only  thing  different  would  be  the  representa¬ 
tion  of  the  logic. 

3.4.2  Example  Stylized  Machine .  As  the  work  for  this 
thesis  began,  a  search  was  made  for  potential  example  sys¬ 
tems  to  code  in  the  stylized  form.  It  was  hoped  that  coding 
an  example  system  in  the  JRS  styled  VHDL  would  give  insights 
into  possible  translation  difficulties. 

The  first  design  selected  for  conversion  to  JRS  IDAS 
style  was  a  central  processing  unit  (CPU)  controller  written 
by  Richard  L.  Miller  as  part  of  his  AFIT  thesis  effort 
(Miller,  1990).  After  a  couple  of  weeks  of  trying  to  deter¬ 
mine  how  the  IDAS  environment  (including  the  styled  VHDL, 
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the  IDAS  procedures,  and  the  IDAS  system)  could  model  the 
controller,  a  careful  investigation  revealed  the  CPU  con¬ 
troller  was  modeled  as  a  state  machine  instead  of  a  "real" 
machine,  and  the  CPU  controller  did  not  represent  the  mini¬ 
mum  system  required  for  the  IDAS  to  generate  microcode. 

After  the  CPU  controller  was  ruled  out,  it  was  decided 
the  simple  CPU  described  by  Hayes  would  serve  as  the  basis 
for  the  IDAS  example  (Hayes,  1988:315).  Hayes'  CPU  provided 
all  the  components  necessary  for  the  IDAS  to  generate  micro¬ 
code.  It  consists  of  a  control  store,  instruction  register, 
program  counter,  address  register,  memory,  data  register, 
accumulator,  and  arithmetic  logic  unit. 

The  first  attempt  at  the  Hayes  model  was  to  design  the 
entities  with  ports  that  connected  to  all  associated  enti¬ 
ties.  This  is  a  direct  translation  from  the  diagram  (see 
Figure  3-8)  provided  by  Hayes  (Hayes,  1988:315).  However, 
after  coding  the  example  in  that  fashion,  it  was  determined 
that  the  direct  translation  of  the  diagram  was  not  a  realis¬ 
tic  implementation. 

After  careful  consideration,  the  model  in  Figure  3-8 
was  perceived  to  be  a  logical  representation  of  the  system. 

A  more  accurate  "physical"  representation  of  the  system  was 
needed  to  gain  insight  into  the  correct  structure  for  the 
VHDL  code.  Figure  3-9  provides  this  structural  view  of  the 
simple  Hayes  model . 
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Figure  3-8.  Simple  CPU  as  Presented  by  Hayes 
(Hayes,  1988:315) 

Early  versions  of  the  Hayes  model  did  not  properly 
account  for  circuit  timing  characteristics.  The  first 
version  was  the  idealistic  no-delay  version.  Then,  delays 
were  added  to  the  bus  and  in  later  versions  to  the  compo¬ 
nents  . 

Through  version  4,  the  Hayes  model  was  written  using  a 
WAIT  statement  inside  the  behavioral  IF  statements  contain¬ 
ing  IDAS  procedure  calls .  During  a  review  of  the  VHDL  Style 
Guide,  it  was  discovered  that  this  is  not  allowed.  The 
delay  had  to  be  moved  to  the  signal  assignment  statements 
after  the  procedure  call.  Hayes  simple  CPU  version  5  is  now 
believed  to  be  totally  in  the  style  required  by  the  JRS 


3.27 


/ . - - - - ---\ 

I  i 

I  m:=o  I 


\ - - - - - / 

Figure  3-9.  Structural  View  of  Hayes  Model 

IDAS.  Appendix  A  contains  the  final  version  of  the  stylized 
Hayes  CPU  model,  and  Volume  II  contains  a  simulation  listing 
which  is  annotated  with  the  machine  instructions  being 
executed  each  cycle.  (Note:  Volume  II  is  used  to  maintain 
restricted  access  information  and  computer  listin^^s  which 
could  not  be  formated  for  inclusion  in  Volume  I). 

Unfortunately,  when  the  JRS  IDAS  was  run  to  enter  the 
Hayes  model,  it  would  not  take  it.  The  nice  graphical 
interface  written  to  enter  VHDL  designs,  analyze  them  in  the 
IDAS  database,  enter  Ada  code  to  tune  the  generated  micro¬ 
code.  and  check  the  VHDL  design  into  the  microcode  genera¬ 
tion  process  did  not  work  for  checking  in  the  Hayes  units. 

Aacitionally ,  a  local  IDAS  expert  was  contacted  (who  in 
turn  contacted  JRS)  and  manual  procedures  were  attempted  to 
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load  the  units  in  the  system  through  a  complicated  sequence 
of  maneuvers,  but  to  no  avail.  The  portion  of  the  IDAS  re¬ 
quired  for  this  thesis  did  not  work.  This  was  a  setback  for 
this  thesis,  for  it  was  now  not  possible  to  test  the  conclu¬ 
sions  of  the  analysis  against  an  actual  tool.  Yet,  the 
analysis  provided  valuable  insight  into  the  obstacles  to 
translating  VHDL  into  a  subset  of  VHDL. 

3.4.3  Lessons  Learned  From  Example .  The  lessons 
learned  from  the  Hayes  example  were  probably  lessened  due  to 
the  inability  to  run  the  design  through  the  IDAS.  Be  that 
as  it  may,  some  valuable  ideas  did  come  from  the  Hayes 
modeling  exercise. 

It  is  possible  to  translate  a  physical  design  into  a 
JRS  styled  VHDL  description  using  the  JRS  procedures  and 
gain  a  correct  implementation  --an  implementation  that 
gives  correct  results  when  run  through  a  VHDL  simulation. 

The  Hayes  example  therefore  indicates  that  other  designs 
should  work  if  translated  to  the  JRS  style. 

During  development  and  implementation  of  the  Hayes  CPU, 
it  was  easy  to  use  a  perfectly  allowable  construct  in  VHDL, 
but  then  learn  it  was  not  allowed  by  the  JRS  style.  This 
indicated  a  need  for  a  detailed  analysis  and  design  of  each 
mapping  needed  to  transform  standard  VHDL  into  the  JRS 
style.  It  also  highlighted  the  need  for  an  automated  tool 
to  do  the  translating,  since  humans  make  errors  when  given 
such  a  complex  task. 
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Not  much  was  learned  regarding  the  translation  of  types 
and  functions  since  the  Hayes  model  was  originally  built 
using  JRS'  VHDL  Style  Guide.  A  more  realistic  system  was 
needed  to  test  mappings  for  types  and  functions  and  to 
verify  the  feasibility  of  mappings  required  by  IDAS  which 
were  not  exercised  during  the  Hayes  implementation.  The 
system  chosen  for  use  during  the  remaining  development  of 
Style-V  was  the  Floating-Point  Arithmetic  Shift  Processor 
(FPASP) .  The  FPASP  was  complex  enough  to  test  most  of  the 
mappings  required  for  standard  VHDL  to  the  JRS  IDAS  styled 
subset . 

3.4.4  Stylized  Limitations .  A  great  concern  when 
going  from  a  design  coded  in  a  general  language  to  a  more 
restricted  form  is  the  need  to  maintain  all  the  functionali¬ 
ty  of  the  design.  The  IDAS  will  maintain  functionality  of 
functions  which  map  to  IDAS  provided  functions.  However, 
since  the  IDAS  allows  user-defined  functions  which  it  does 
not  understand  or  use,  it  is  not  clear  that  design  function¬ 
ality  is  maintained  --  apparently,  functionality  would  be 
lost  in  the  conversion.  Also,  adding  functions  to  the  IDAS 
is  not  a  user  option  --  it  requires  a  request  to  JRS  which 
entails  an  implementation  waiting  time,  a  possibility  the 
request  would  not  be  accepted,  and  most  likely,  a  charge  for 
the  service. 

An  additional  concern  of  function  mapping  is  how  to  do 
it.  Is  it  even  possible  to  determine  if  two  sections  of 
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code  are  functionally  equivalent?  For  an  example  of  the 
difficulty  of  this  problem,  consider  the  two  simple  proce¬ 
dures  in  Figure  3-10. 

The  procedure  George  performs  an  ADD  operation  on  two 
3 2 -bit  bit_vectors  using  AND  and  OR  gates.  The  procedure 
Brad  also  performs  an  ADD  on  two  3 2 -bit  bit_vectors,  but 
Brad  uses  the  more  common  XOR,  AND,  and  OR  combinations  to 
accomplish  the  ADD.  Note  that  none  of  the  variables  of 
either  procedure  have  a  name  that  matches  the  other  proce¬ 
dure  —  just  like  the  flexibility  in  a  real  programming 
language.  Without  carefully  analyzing  the  logic,  it  is 
virtually  impossible  to  map  these  "functionally  equivalent" 
procedures  to  one  another. 

A  naive  approach  might  be  to  test  the  code  segments  for 
a  given  input  or  set  of  inputs,  and  this  might  work  for  a 
small  number  (say  N)  examples.  However,  an  implementation 
that  does  this  r  <s  accepting  a  mapping  that  is  incorrect 
for  input  (N  +  Additionally,  as  more  complexity  is 

encompassed  in  a  design,  the  number  of  tests  increases 
dramatically.  Consider  our  simple  sample  procedures  of 
Figure  3-10. 

Given  the  two  32-bit  inputs  (each  having  2^^  possible 
values)  and  an  additional  input  bit  (which  has  two  possible 
values) ,  the  total  number  of  possible  inputs  is 
232  *  2^2  *  2  =  =  2^^  «  3.689  *  10^^.  A  computer 

processing  100  procedure  runs  per  second  would  take  about 
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11,697,742,263  years  to  test  all  possibilities. 

Style-V's  problem  of  mapping  existing  functions  is 
different  than  the  problem  of  translating  a  function  from 
one  language  into  another.  The  translators  and  methods 
reviewed  in  Chapter  2  provide  many  examples  of  how  a  "trans¬ 
lation"  is  done. 

Two  technologies  currently  exist  to  perform  transla¬ 
tions  --  transliteration  and  refinement  or  abstraction  and 
reimplementation.  Translations  by  transliteration  and 
refinement  are  usually  line-by-line  conversions  of  function¬ 
ally  well  defined  statements  of  one  language  into  function¬ 
ally  well  defined  statements  of  a  target  language.  Transla¬ 
tions  by  abstraction  and  reimplementation  involve  mapping 
the  logic  of  an  input  program  into  formally  defined  layers 
of  abstraction  and  then  by  mapping  the  formally  defined 
abstraction  into  a  program  in  the  target  language. 

Unfortunately,  Style-V  needs  to  map  nonatomic  functions 
(multiple  statements  with  unique  logic)  for  which  meaning  is 
not  known  to  specific  nonatomic  functions  for  which  meaning 
is  known.  Neither  transliteration  and  refinement  nor  ab¬ 
straction  and  reimplementation  can  solve  this  problem. 

Since  it  is  realistically  impossible  to  ensure  a  completely 
correct  mapping  automatically,  Style-V  requires  human  inter¬ 
vention  to  perform  this  task. 
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Procedure  George  (OPl,  0P2  :  in  BIT_VECTOR; 


CARRY_IN  :  in  BIT; 

SUM  ;  out  BIT_VECTOR(31  down to  0); 

CARRY_OUT  :  out  BIT); 
variable  LCL_CRY,  :  BIT; 

variable  i  :  INTEGER  :=  0; 

Begin  --  George 

LCL_CRY  :=  CARRY_IN; 
for  i  in  0  to  31  loop 

SUM(i)  :=  OPl(i)  and  OP2(i); 

SUM(i)  :=  SUM(i)  and  LCL_CRY; 
if  (  ((OPl(i)  =  '1')  and  (OP2(i)  =  '1')) 
or  ((OPl(i)  =  '1')  and  (LCL_CRY  =  '1')) 
or  ((OP2(i)  =  '!')  and  (LCL_CRY  =  '1')) 
) 

then  LCL_CRY  :=  '1'; 
else  LCL_CRY  :=  'O'; 
end  if; 
end  loop; 

CARRY_OUT  :=  LCL_CRY; 

End  George; 


I  Procedure  Brad  (INI,  IN2  :  BIT_VECTOR  (31  downto  0);  | 

I  IN3  :  bit;  | 

1  OUTl  :  out  Bit;  | 

1  OUT2  :  out  BIT_VECTOR  (31  downto  0)  );  | 

I  variable  LC,  LR,  Zl,  Z2  :  BIT;  1 

I  variable  J  :  INTEGER;  I 

I  begin  I 

I  LC  :=  IN3;  | 

I  for  J  in  0  to  31  loop;  I 

I  LR  :=  INl(J)  xor  IN2(J);  I 

I  Zl  :=  INl(J)  and  IN2(J);  | 

I  OUT2  :=  LR  xor  LC;  I 

I  Z2  :=  LR  and  LC;  I 

I  LC  :=  Zl  or  Z2;  I 

I  end  loop;  | 

I  OUTl  :=  LC;  I 

j  end  Brad;  I 

I  I 

\ . . - . - . . .  / 

Figure  3-10.  Two  "Functionally  Equivalent"  Procedures 


A  later  version  of  Style-V  might  consider  using  a 
"partial  testing"  method  to  get  a  "first  cut"  mapping  which 
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the  user  could  run  against  representative  input  to  "verify" 
correctness.  This  would  entail  a  fairly  sophisticated 
mechanism  for  taking  VHDL  procedures  as  input,  determining 
input  for  the  procedures,  processing  input  through  them, 
comparing  the  output  to  output  generated  by  IDAS  procedures 
with  the  same  number  of  input  and  output  parameters,  and 
determining  if  a  match  occurred.  If  the  automatic  mappings 
proved  to  be  incorrect,  the  user  could  rerun  the  translator 
with  a  switch  set  turning  the  automatic  mapping  function 
off.  This  process  alone  might  be  a  good  thesis  topic  for 
some  future  thesis  effort. 

Another  limitation  which  may  not  allow  the  complete 
functionality  of  an  original  design  to  be  maintained  in  a 
translation  is  the  limited  typing  of  JRS  styled  VHDL. 
Apparently,  the  mapping  of  machine  specific  words  from 
multilevel  logic  to  bit  logic  is  possible  and  functionality 
can  be  preserved  (See  Section  3. 4. 1.1).  However,  the  map¬ 
ping  of  types  for  GENERIC  statements  and  the  limited  modes 
available  for  types  may  limit  functionality  of  a  translated 
design.  Since  translation  to  JRS  IDAS  styled  VHDL  requires 
some  types  to  be  mapped  to  a  more  general  type,  it  is  not 
clear  if  the  same  functionality  will  be  maintained  in  all 
cases,  though  it  is  expected  the  new  design  will  suffice  for 
microcode  generation  purposes. 

A  limitation  which  has  been  solved  by  this  thesis  is 
the  modeling  of  multilevel  logic.  This  can  now  be  accom- 
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plished  using  the  JRS  styled  BIT  logic  (See  Section 
3. 4. 1.1).  An  additional  benefit  is  the  limitation  on  tris¬ 
tate  busses  stated  in  the  JRS  VHDL  Style  Guide  need  not  be  a 
concern  since  multilevel  logic  can  be  modeled. 

Though  not  necessarily  a  functionality  concern,  the 
restriction  of  tracking  status  using  the  JRS  defined 
STATUS_TYPE  and  STATUSVECTOR  is  a  difficult  translation 
task.  This  research  did  not  find  an  automated  way  to  map 
status  variables  or  signals  to  JRS  procedures  and  their 
associated  STATUSTYPE  without  manual  intervention  or  possi¬ 
bly  the  need  for  some  type  of  definition  file  in  addition  to 
the  VHDL  code  of  the  design. 

3.5  Modern  Structured  Analysis 

Modern  structured  analysis  provides  a  method  for 
achieving  a  detailed  specification  of  a  problem.  The  speci¬ 
fication  is  the  most  important  part  of  a  development  effort, 
for  every  action  taken  after  the  specification  is  directed 
toward  fulfilling  the  requirements  documented  in  it. 

Not  only  does  modern  structured  analysis  provide  a 
vehicle  for  providing  well-stated  and  un"  biguous  specifica¬ 
tions,  it  also  provides  that  information  in  a  format  that 
facilitates  modular,  functional  design.  Every  major  func¬ 
tion  is  defined  with  its  inputs  and  outputs  during  the 
modern  structured  analysis  process.  The  first  st 3p  in  this 
process  is  the  definition  of  the  system  context. 


3 . 35 


3.5.1  Style -V  Translator  System  Context .  When  build¬ 


ing  anything,  including  a  software  system,  the  first  step 
during  problem  analysis  is  to  determine  how  the  problem 
relates  to  the  world  around  it.  For  a  translator,  and 
specifically  for  Style-V,  the  world  represents  the  inputs  it 
expects  and  the  outputs  expected  of  it.  Inputs  can  come 
from  external  entities  such  as  users  or  data  stores,  and 
outputs  can  go  to  the  same  (Davis,  1990:91). 

Figure  3-11  provides  a  level  zero  DFD  (context  diagram) 
showing  the  system  context  for  Style-V.  This  figure  dis¬ 
plays  a  user  entity  which  inputs  commands  and  responses  to 
the  system,  the  input  files  coming  from  a  data  store  con¬ 
taining  VHDL  source  files,  status  information  and  system 
requests  going  back  to  the  user,  and  output  files  going  to  a 
data  store.  At  this  level  of  abstraction,  this  is  the  only 
level  of  detail  allowed. 


Figure  3-11.  Style-V  System  Context  Diagram 
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3.5.2  Style-V  External  Events .  Once  the  system  con¬ 


text  is  defined  and  understood,  the  next  step  is  to  com¬ 
pletely  specify  the  external  events  affecting  the  system. 
This  specification  takes  the  form  of  a  narrative  event  list 
(Davis,  1990:91).  The  narrative  should  cover  all  the  ac¬ 
tions  necessary  to  translate  VHDL  files  from  a  standard  form 
into  a  stylized  form.  Therefore,  the  External  Event  List 
(EEL)  should  describe  all  the  external  actions  necessary  to 
facilitate  the  mappings  described  by  Section  3.4.1,  Figure 
3-6 . 

At  first  glance,  it  would  seem  that  many  actions  would 
be  required  to  facilitate  the  thirteen  mappings  identified 
in  Figure  3-6.  However,  a  careful  look  at  the  context 
diagram  shows  that  the  only  entities  outside  the  Style-V 
system  that  act  upon  it  are  the  user  entity  and  the  input 
files  of  VHDL  source  code. 

Only  one  input  from  the  user  would  tell  the  system  to 
partially  or  completely  stylize  a  file,  group  of  files,  or 
the  entire  design.  Then,  Style-V  would  request  the  file 
from  the  VHDL  source  store  and  perform  all  the  internal 
actions  necessary  to  stylize  the  file.  Style-V  would  only 
ask  for  more  input  if  manual  intervention  was  necessary  or 
if  a  recoverable  error  occurred.  The  user  would  then  input 
an  appropriate  response.  With  this  overview,  it  is  then 
relatively  easy  to  derive  the  event  list  for  the  process. 

The  event  list  is  provided  in  Figure  3-12. 
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I 

User  requests  to  stylize  a  directory  of  files.  I 

I 

User  requests  to  style  TYPES  for  a  file.  | 

I 

User  requests  CASE  to  IF  statement  conversion.  | 

I 

User  requests  to  build  MACHINE_DECLARATIONS .  I 

I 

User  requests  architecture  conversion  for  a  file.  | 

I 

User  requests  processing  of  tests  for  data  values.  | 

I 

User  requests  Procedure  Mapping .  | 

I 

User  responds  to  Style-V  requests.  | 

I 

VHDL  source  data  store  provides  needed  files.  | 

I 

VHDL  source  data  store  accepts  translated  files.  I 

I 
I 

(note:  all  Figure  3-6  mappings  included  above.)  | 

I 

\ . . . / 

Figure  3-12.  Style-V  External  Event  List 

3.5.3  Style-V  Event  Behaviors ♦  When  deciding  how  each 
external  event  affects  a  system,  the  analyst  needs  to  deter¬ 
mine  which  operations  of  a  system  affect  other  operations 
within  the  system.  With  this  knowledge,  the  analyst  can 
avoid  proposing  a  course  of  action  which  will  cause  a  con¬ 
flict  later  in  the  development  phase. 

For  the  Style-V  translation  task,  a  review  of  the 
external  events  and  the  expected  output  of  each  shows  that 
the  actions  required  to  stylize  a  VHDL  file  are  orthogonal 
-  -  each  action  can  be  performed  independently  of  the  other 
actions  and  in  any  order,  and  the  results  will  be  the  same. 
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Therefore,  any  of  the  processes  required  of  the  Style -V 
translator  can  be  done  without  concern  for  which  other 
Style -V  processes  have  been  done  or  will  yet  be  done. 

Identifying  the  external  events  may  have  been  simple, 
but  specifying  all  the  behaviors  of  the  system  in  response 
to  those  external  events  is  not.  This  section  contains  an 
explanation  of  the  actions  performed  by  Style-V  in  response 
to  external  events .  This  explanation  must  be  detailed 
enough  to  facilitate  the  design  phase  in  Chapter  4. 

In  Figure  3-12,  the  various  external  events  were  summa¬ 
rized.  The  first  event  was  a  user's  request  to  stylize  all 
files  in  a  directory.  This  operation  entails  a  combination 
of  all  the  separate  actions  identified  in  Figure  3-12. 
Therefore,  a  detailed  description  of  this  action  will  best 
be  given  after  each  of  the  separate  actions  is  explained. 

3 . 5 . 3 . 1  Type  Conversion .  A  major  requirement  for 
stylizing  a  VHDL  design  is  to  convert  the  standard  and  user- 
defined  types  to  a  type  allowed  by  the  JRS  VHDL  subset. 

This  involves  scanning  an  input  file  for  type  declarations, 
checking  those  declarations  to  determine  if  they  are  compat¬ 
ible  with  types  allowed  in  the  VHDL  subset,  and  converting 
types  that  are  not  compatible.  A  first  pass  over  the  file 
converts  all  types  to  a  subset  compatible  types  and  the 
result  is  written  to  an  intermediate  file.  Generic  clause 
types  are  converted  automatically  unless  no  clear  mapping 
exists,  and  then  the  user  is  asked  to  identify  an  acceptable 
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type.  All  of  these  conversions  are  collected  in  a  temporary 
file.  Since  it  is  impossible  to  determine  which  types  are 
used  for  status  tracking,  the  user  is  then  asked  to  identify 
which  types  are  used  to  track  status  and  a  second  pass  over 
the  file  converts  those  types  to  JRS  IDAS  Status_Types .  A 
high  level  model  of  the  type  conversion  process  is  provided 
in  Figure  3-13.  A  more  detailed  view  will  be  described  in 
Section  3.5.4. 


Figure  3-13.  Type  Conversion  Data  Flow  Diagram 


3 . 5 . 3 . 2  CASE  to  IF  Conversion .  Since  the  JRS 
IDAS  style  of  VHDL  does  not  permit  the  VHDL  CASE  statement, 
Style-V  must  translate  CASE  statements  to  equivalent 
IF  statements.  The  method  chosen  to  perform  this  task  is 
transliteration  and  reimplementation. 
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The  translation  process  consists  of  several  steps.  The 
first  is  to  read  an  input  file  until  the  keyword  CASE  is 
recognized,  convert  it  to  IF,  and  write  it  to  the  output 
file.  The  second  task  is  to  read  the  conditional  variable 
and  store  it  as  a  string  for  use  in  the  IF,  ELSIF,  and  ELSE 
portions  of  the  IF  statement.  The  input  file  is  read  until 
the  value  after  the  first  WHEN  is  read,  then  the  string  is 
written  for  the  conditional  variable,  the  symbol  and 

the  value  to  the  output  file.  The  next  word  is  read  from 
the  input  which  should  be  a  "=>"  symbol  and  the  word  THEN  is 
written  to  the  output  file.  Now  the  WHEN  clause  body  should 
be  read  and  passed  through  to  the  output  file  until  the 
keyword  WHEN  is  recognized  again.  Then  the  word  after  WHEN 
is  read.  If  the  word  after  WHEN  is  a  value  for  the  condi¬ 
tional  variable  and  not  the  keyword  OTHERS,  the  phrase  ELSIF 
followed  by  the  variable  value  is  written  to  the  output 
file.  If  the  keyword  OTHERS  was  found,  the  phrase  ELSE  is 
written  to  the  output  file.  If  an  ELSIF  phrase  was  written, 
when  the  word  "=>"  is  recognized  the  word  THEN  is  written  to 
the  output  file,  otherwise  it  is  ignored.  The  WHEN  clause 
phrase  is  passed  through  until  the  key  word  phrase  END  CASE 
is  recognized.  This  process  is  represented  by  a  high  level 
description  in  Figure  3-14.  A  more  detailed  view  will  be 
described  in  Section  3.5.4. 

3 . 5 . 3 . 3  Build  Machine  Declarations .  The  machine 
specific  declarations  for  a  design  must  be  located  in  a 
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Figure  3-14.  CASE  to  IF  Conversion  Data  Flow  Diagram 

package  called  MACHINE_DECLARATIONS  for  a  design  specified 
for  the  JRS  IDAS.  To  successfully  build  this  package,  three 
types  of  inf'  .mation  must  be  collected  and  formed  into  the 
package.  The  first  piece  consists  of  the  CYCLE_LENGTH  which 
is  the  length  of  time  for  one  instruction  fetch  cycle.  The 
second  piece  consists  of  the  declarations  of  the  machine 
which  use  types  other  than  those  provided  in  the  JRS 
Data_Types  package.  The  final  piece  consists  of  the  decla¬ 
rations  representing  buses  and  their  corresponding  resolu¬ 
tion  functions. 

Since  no  standard  notation  exists  for  defining  clock 
cycles,  the  CYCLE_LENGTH  may  be  difficult  or  even  impossible 
to  determine  from  the  raw  input  files.  For  this  data  item, 
a  query  to  the  user  is  the  method  used  by  Style-V. 
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To  successfully  create  MACHINE_DECLARATIONS,  the  user 
must  provide  a  list  of  the  file  names  wherein  VHDL  source  is 
located.  This  input  could  be  a  list  of  file  names  or  possi¬ 
bly  a  directory  name  if  all  files  in  the  directory  are  to  be 
processed. 

When  processing  machine  declarations  from  different 
files,  Style -V  must  not  duplicate  the  same  type  name  from 
different  files.  To  facilitate  this  process,  Style-V 
creates  a  table  of  declarations  for  each  file.  These  tables 
are  then  compared  to  determine  if  a  conflict  would  exist  in 
the  new  MACHINE_DECLARATIONS  package.  Also,  as  each  file  is 
processed,  when  USE  clauses  are  encountered,  the  package 
name  for  the  package  containing  the  USE  clause  is  appended 
to  a  list  representing  the  package  identified  in  the  USE 
clause.  By  tracking  which  packages  use  a  package  wherein 
declarations  are  defined,  if  name  changes  due  to  conflicts 
are  required,  the  name  changes  can  be  properly  propagated. 

Style-V  recognizes  bus  declarations  by  determining  if  a 
resolution  function  is  part  of  the  declaration.  This  is 
relatively  easy  to  determine  since  the  input  is  validated 
VHDL  code.  Therefore,  if  a  declaration  has  a  multiword  type 
definition,  it  will  be  a  bus  type.  The  name  of  the  resolu¬ 
tion  function  will  be  extracted  and  used  later  when  Style-V 
collects  all  resolution  functions  in  MACHINE_DECLARATIONS . 

The  processing  necessary  to  create  MACHINE_DECLARATIONS 
requires  multiple  passes  over  the  files.  A  final  pass 
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removes  all  declarations  from  the  files  that  were  written  to 
package  MACHINE_DECIiARATIONS .  The  high  level  view  of  the 
process  described  above  is  pictorially  described  in  Figure 
3-15.  A  more  detailed  view  will  be  described  in  Section 
3.5.4. 


Figure  3-15.  Create  MACHINE_DECLARATIONS  DFD 


3 . 5 . 3 . 4  Architecture  Conversion .  Since  JRS  IDAS 
style  VHDL  does  not  allow  multiple  concurrent  statements  in 
an  architecture,  architectures  containing  BLOCK  statements 
or  multiple  process  statements  must  be  converted  into  archi¬ 
tectures  with  only  one  process  statement.  The  overall 
description  of  the  requirement  to  convert  standard  VHDL 
architectures  into  JRS  single  process  architectures  was 
given  in  Section  3. 4. 1.3.  When  requesting  architecture 
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conversion,  the  user  must  specify  which  file  or  files  re¬ 
quires  conversion.  The  user  can  specify  this  by  a  file  list 
or  a  directory  if  all  files  in  the  directory  are  to  be 
processed. 

For  each  file  of  the  system,  five  steps  are  required  to 
convert  multiprocess  architectures  (possibly  including  block 
statements)  into  single-process  architectures  with  no  block 
statements.  The  first  step  is  to  collect  statements  which 
are  not  part  of  any  block  or  process  in  the  architecture  and 
put  them  in  the  statement  part  of  a  new  high  level  architec¬ 
ture  which  will  encompass  all  the  architectures  formed  by 
the  next  three  steps .  The  second  step  is  to  convert  block 
statements  into  process  statements.  The  third  step  is  to 
create  an  entity  for  each  of  the  processes  formed  from  the 
original  architecture  in  step  2.  The  fourth  step  is  to 
create  an  architecture  for  each  of  the  entities  created  in 
step  3.  Finally,  the  fifth  step  is  to  form  the  architec¬ 
tures  produced  for  each  process  into  a  higher  level  archi¬ 
tecture  with  the  same  name  as  the  original  architecture.  In 
this  way,  only  the  internal  composition  has  changed.  The 
functionality  and  external  view  of  the  architecture  remains 
the  same.  The  remainder  of  this  section  discusses  the 
activities  of  each  step.  A  real  world  example  using  the 
FPASP  design  is  provided  in  Chapter  4. 

The  activity  of  step  1  (collecting  statements  which  are 
not  part  of  any  PROCESS  or  BLOCK  statement)  is  a  simple 
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matter  of  collecting  statements  which  occur  outside  any 
BLOCK  or  PROCESS  statement  while  parsing  the  architecture. 
The  new  architecture  will  eventually  consist  of  the  original 
entity  description,  an  architecture  which  defines  and  in¬ 
stantiates  components  for  each  of  the  subarchitectures 
created  in  steps  2  through  4,  and  a  statement  part  contain¬ 
ing  the  statements  collected  which  did  not  belong  to  any 
block  or  process. 

The  activity  of  step  2  (turning  a  BLOCK  statement  into 
a  PROCESS  statement)  entails  determining  and  storing  the 
guard  of  the  BLOCK  statement.  The  statement  starting  the 
block  is  deleted.  As  the  next  lines  are  parsed,  declara¬ 
tions  before  the  keyword  BEGIN  are  found.  If  declarations 
are  found,  they  are  kept  in  storage  for  future  use.  When 
the  keyword  BEGIN  is  reached  (the  block's  begin),  it  is 
deleted.  All  statements  are  stored  until  a  PROCESS  state¬ 
ment  is  found.  Then,  as  each  process  is  encountered,  the 
contents  of  any  sensitivity  list  are  stored.  The  keyword 
PROCESS  is  maintained,  but  the  sensitivity  list  is  deleted. 
Next,  any  declarations  stored  from  the  block  is  copied  into 
the  process.  Then,  the  declarations  are  parsed  until  the 
process  BEGIN  is  found.  Next,  a  WAIT  statement  with  an 
UNTIL  clause  for  the  stored  block  guard  and  an  ON  clause  for 
the  stored  sensitivity  list  is  inserted  as  the  first  state¬ 
ment  of  the  process.  Next,  any  statements  copied  from  the 
BLOCK  statement  are  placed  into  the  PROCESS  statement  after 
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the  wait.  This  process  has  not  only  "moved"  the  block  to 
the  process,  but  has  stylized  the  process  entry.  Now,  the 
process  is  parsed  passing  through  all  information  until  the 
END  PROCESS  phrase  has  been  passed  through.  These  actions 
are  repeated  for  any  additional  processes  (using  their 
sensitivity  lists).  When  the  END  BLOCK  phrase  is  found,  it 
is  deleted. 

The  activity  of  step  3  (creating  an  entity  for  each 
PROCESS  statement)  entails  identifying  the  ports  and  aliases 
for  port  portions  used  in  the  process,  identifying  any 
generic  clause  items  referenced  in  the  process,  and  forming 
the  entity  description  for  the  process  based  on  the  collect¬ 
ed  information.  To  properly  perform  this  task,  the  gener¬ 
ics,  ports,  and  aliases  identified  in  the  original  entity 
and  architecture  must  be  known.  These  can  be  collected  in 
lists  during  the  initial  parsing  of  the  original  entity  and 
architecture.  Only  those  generics,  ports,  and  aliases  used 
in  the  process  need  be  included  in  the  new  entity  for  the 
new  process  architecture.  Later,  when  the  subarchitectures 
are  combined  under  a  new  architecture  with  the  original 
name,  the  entity  generics  and  ports  will  map  to  the  appro¬ 
priate  ports  or  port  portions  of  the  original  entity  (which 
stays  intact  during  this  entire  transformation  process). 

The  activity  of  step  4  (creating  an  architecture  for 
each  new  process  statement  and  entity)  is  one  of  the  easier 
steps  of  the  transformation  process.  The  architecture 
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declaration  is  of  the  form  "architecture  BEHAVIOR  of  ENTITY- 
NAME  is,"  and  it  is  followed  by  BEGIN  which  is  followed  by 
the  process  and  the  architecture  is  completed  with  an  "end 
BEHAVIOR"  clause  after  the  process  statement. 

The  activity  of  step  5  (creating  a  new  higher  level 
architecture)  consists  of  defining  and  instantiating  compo¬ 
nents  of  the  new  subarchitectures  and  connecting  them  to  the 
appropriate  ports  of  the  original  entity  using  newly  defined 
signals.  Since  the  JRS  style  of  VHDL  required  components  to 
have  the  same  name  and  the  same  ports  as  the  entity  for 
which  they  are  defined,  this  is  a  relatively  easy  task. 
Entity  AN_ITEM  with  ports  IN1_P0RT,  IN2_P0RT,  and  0UT1_P0RT 
would  be  represented  by  component  AN_ITEM  with  ports 
IN1_P0RT,  IN2_P0RT,  and  0UT1_P0RT.  The  component  instance 
will  have  a  unique  instance  name  and  use  the  component  name 
(entity  name)  and  a  port  map  of  the  component  (entity)  ports 
assigned  to  locally  defined  signals  of  the  same  type  as  the 
component  ports.  The  locally  defined  signals  are  easy  to 
create  since  one  each  is  required  for  each  of  the  original 
entity  ports  (name  and  type  come  from  stored  record  of 
original  entity  ports).  After  all  the  components  represent¬ 
ing  the  new  subarchitectures  are  instantiated,  the  new 
architecture  is  complete. 

A  second  task  to  make  architectures  correct  for  the  JRS 
IDAS  system  is  to  ensure  structural  architectures  have  no 
delays  associated  with  their  signal  assignments.  If  delay 
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is  required,  a  behavioral  architecture  MOVE  statement  must 
be  used  to  model  the  wait.  Version  1  of  Style -V  will  not 
provide  synthesis  of  behavioral  from  structural  or  structur¬ 
al  from  behavioral  architectures;  therefore,  manual  inter¬ 
vention  will  be  required  to  ascertain  if  a  delay  is  abso¬ 
lutely  necessary.  If  the  delay  is  needed,  the  Style-V  will 
return  the  file  to  the  user  for  modification. 

A  third  process  needed  to  ensure  architectures  are 
stylized  is  to  ensure  component  names  and  ports  match  exact¬ 
ly  with  the  entity  defining  the  components.  This  was  taken 
care  of  for  the  components  created  for  the  new  architec¬ 
tures.  However,  other  components  which  do  not  meet  these 
strict  requirements  may  exist  in  other  parts  of  the  system. 
Therefore,  a  process  of  Style-V  will  need  to  check  the  files 
of  the  system  for  components  which  do  not  match  their  re¬ 
spective  entity. 

Since  one  entity  may  define  several  components  in 
standard  VHDL  (all  of  which  may  have  different  names  and 
ports  defined),  three  actions  are  required  to  ensure  compo¬ 
nents  are  properly  defined.  First,  Style-V  will  make  a  copy 
of  the  entity  and  its  associated  architecture  with  the  name 
of  the  component.  Secondly,  the  ports  of  the  component  will 
be  adjusted  to  look  exactly  like  the  entity,  even  though  not 
all  will  be  connected  to  "live"  signals  when  the  component 
is  wired  into  an  architecture.  Finally,  Style-V  adjusts 
component  instantiations  to  match  their  corresponding 
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declarations  and  assigns  "dummy"  signals  to  the  ports  not 
used  by  the  original  component. 

Finally,  one  task  remains  to  ensure  architectures  are 
in  the  style  expected  by  the  JRS  IDAS.  Any  signal  delay 
that  was  modeled  with  a  WAIT  statement  before  a  signal 
assignment  statement  must  be  transformed  into  a  signal 
assignment  with  an  AFTER  clause  and  no  preceding  WAIT  state¬ 
ment.  This  requires  one  pass  over  the  files  with  a  small 
lookahead  buffer  to  see  if  a  WAIT  statement  precedes  a 
signal  assignment  statement.  Output  from  the  buffer  will  go 
directly  to  the  output  files. 

When  the  four  processes  described  above  are  complete, 
(forming  single-process  architectures,  removing  delay  from 
structural  architectures,  aligning  component  to  entity 
mapping,  and  positioning  wait  in  behavioral  architectures) 
the  architectures  of  the  design  are  in  the  form  required  by 
the  JRS  IDAS.  As  with  the  main  processes  required  for  the 
overall  stylization  of  standard  VHDL  into  the  JRS  form,  the 
subprocesses  required  to  transform  architectures  into  the 
JRS  form  are  orthogonal .  None  depend  on  the  results  of  a 
previous  process  and  they  can  be  performed  in  any  order. 

A  high  view  of  architecture  processing  is  presented  in 
Figure  3-16,  and  a  conceptual  view  of  the  four  main  process¬ 
es  necessary  to  complete  architecture  processing  is  present¬ 
ed  in  Figure  3-17.  More  detail  will  be  provided  in  Section 
3.5.4. 
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Figure  3-16.  Architecture  Conversion  Data  Flow  Diagram 
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Figure  3-17.  Main  Architecture  Processes  DFD 


3 . 5 . 3 . 5  Validate  Condition  Tests .  To  satisfy  the 
JRS  requirement  that  no  tests  for  data  values  occur,  Style-V 
must  check  each  IF  statement  clause  to  ensure  no  such  tests 


are  being  done.  Style -V  must  identify  the  control  word  and 
all  aliases  to  it  and  all  system  clocks,  since  tests  on 
these  values  are  allowed.  As  stated  in  an  earlier  section, 
JRS  specifically  requires  tests  for  a  clock  value  to  precede 
tests  for  a  control  value. 

Identifying  the  clock  and  control  signals  used  in  the 
system  i:>  relatively  easy,  since  a  process  can  scan  all 
files  and  look  for  declarations  with  type  clock  and  control 
respectively.  Also,  any  aliases  that  use  fields  of  the 
control  variables  are  then  easily  identified. 

Once  the  clock  and  control  variables  are  identified, 
the  process  need  only  parse  all  the  files  of  the  system 
looking  for  IF  statement  conditional  checks.  When  a  condi¬ 
tional  check  is  found,  it  is  checked  to  see  if  it  contains 
anything  other  than  a  test  for  one  of  the  defined  clock  or 
control  variables.  If  it  does,  a  warning  is  output  to  the 
user  that  redesign  of  the  package  in  the  file  must  be  accom¬ 
plished.  The  user  has  the  option  to  continue  checking  for 
more  data  check  violations  or  to  abort  the  check  at  that 
time . 

Conversely,  a  successful  run  is  one  in  which  no  data 
type  violations  are  found.,  A  "SUCCESS"  message  is  printed 
after  each  successful  run.  If  a  run  was  not  successful,  the 
message  printed  after  the  run  will  list  all  packages  and 
files  wherein  violations  occurred. 
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The  validation  of  conditional  tests  Style -V  process  is 
given  in  Figure  13-18.  A  more  detailed  view  will  be  pre¬ 
sented  in  Section  3.5.4. 
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Figure  3-18.  Conditional  Test  Validation  DFD 

3 . 5 . 3 . 6  Map  Procedures .  Probably  the  most  diffi¬ 
cult  task  faced  by  Style -V  is  the  mapping  of  user  defined 
functions  and  procedures  to  JRS  IDAS  procedures .  Section 
3.4.4  contains  an  overview  of  this  problem  and  provides  and 
example  to  show  the  complexity  of  the  task.  The  term 
"function"  used  in  this  section  represents  either  functions 
or  procedures . 

Based  on  the  facts  presented  in  Section  3.4.4,  Style -V 
uses  an  interactive  session  with  the  user  to  map  functions 
to  JRS  IDAS  procedures.  This  requires  the  user  to  have  the 
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IDAS  function  declarations  (and  possibly  even  bodies)  avail¬ 
able  for  comparison  with  their  user-defined  functions. 

The  user  has  two  main  tasks.  The  first  is  to  identify 
the  JRS  IDAS  procedures  which  map  to  their  functions  and 
procedures.  Second,  if  a  function  does  not  map  to  any 
combination  of  IDAS  functions,  the  user  can  either  redesign 
that  function  or  tell  Style-V  to  use  the  function  anyway. 

As  noted  in  an  earlier  section,  including  functions  not 
defined  by  IDAS  is  allowed,  but  the  microcode  generator  will 
not  use  them.  Finally,  if  a  user  defined  function  maps  to  a 
combination  of  IDAS  functions,  the  user  will  need  to  identi¬ 
fy  the  order  of  processing  and  the  parameter  assignments . 

Once  the  user  has  provided  the  procedure  mappings, 
Style-V  comments  out  the  existing  user  defined  function  or 
procedure  declarations  and  their  respective  bodies.  Also, 
all  calls  to  the  previous  user  defined  procedures  are  con¬ 
verted  to  calls  to  appropriate  JRS  IDAS  functions.  Finally, 
a  USE  clause  is  added  to  each  file  of  the  design  so  the 
calls  to  the  JRS  IDAS  procedures  will  work. 

The  high  level  representation  of  the  procedure  mapping 
process  is  represented  in  Figure  3-19.  A  more  detailed 
description  is  provided  in  Section  3.5.4. 

3 . 5 . 3 . 7  Perform  Complete  Stylization .  A  complete 
stylization  entails  performing  all  the  processes  described 
in  Sections  3. 5. 3.1  through  3.5.3. 6.  Figure  3-20  represents 
this  user  option  and  is  displayed  to  indicate  no  specific 
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order  is  required  when  performing  the  stylization  process 
due  to  the  orthogonality  of  the  processes . 


3.5.4  Leveling  of  Style-V  DFDs.  Now  that  the  high 
level  DFDs  for  Style-V  are  defined,  it  is  possible  to  decom¬ 
pose  each  Style-V  process,  capturing  the  decomposition  in  a 
lower  level  DFD.  This  method  is  backwards  to  Ward  and 
Mellor's  method  described  by  Davis  where  the  lowest  level 
DFDs  are  described  first  (DAVIS,  1990:91).  The  reason  is 
that  their  method  works  with  known  tasks  from  an  existing 
system.  Since  Style-V  does  not  yet  exist,  the  top-down 
approach  of  this  thesis  identifies  the  tasks  of  the  system 
by  incremental  decomposition  and  captures  the  results  in 
lower  level  DFDs . 

The  level  1  DFDs  for  the  Style-V  translator  were  pro¬ 
vided  in  Section  3.5.3.  This  section  provides  the  first 
level  of  decomposition  following  level  1.  The  level  2 
diagrams  for  Type  Conversion,  CASE_T0_IF  Conversion,  Create 
MACHINE  DECLARATIONS,  Architecture  Conversion,  Conditional 
Test  Validation,  and  Procedure  Mapping  are  provided  in  this 
section . 

The  level  2  DFD  for  type  conversion  is  presented  in 
Figure  3-21.  The  lexical  and  semantic  processing  of  the 
type  conversion  process  are  more  clearly  visible  at  this 
level.  The  Scan_For_Declarations  process  scans  for  declara¬ 
tion  statements .  When  they  are  found  they  are  passed  to  a 
declaration  converter  process .  All  other  input  is  passed  to 
an  intermediate  file.  After  the  Declaration_Converter 
processed  declarations  to  the  same  intermediate  file.  Then, 
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when  all  of  the  declaration  conversion  is  done,  a 
Status_Type_Converter  process  finishes  the  type  conversion 
process  and  writes  the  output  files. 


Figure  3-21,  Type  Conversion  DFD  --  LEVEL  2 

The  level  2  DFD  for  CASE_To_IF_Conversion  is  provided 
in  Figure  3-22.  The  processes  represented  in  this  DFD  were 
described  in  Section  3. 5. 3. 2.  This  DFD  describes  the  data 
flow  and  processes  necessary  to  implement  the  behavior  of 
the  CASE-To-IF  Conversion  DFD  found  in  Figure  3-14.  A 
medium  level  of  detail  describing  the  actions  necessary  for 
converting  VHDL  CASE  statements  to  VHDL  IF  statements  is 
represented  in  the  DFD  of  Figure  3-22. 
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Figure  3-22.  CASEto_IF  Conversion  DFD  --  Level  2 

The  level  2  DFD  for  collecting  machine  specific  decla¬ 
rations  in  package  MACHINE_DECLARATIONS  is  provided  in 
Figure  3-23.  This  DFD  shows  the  data  flow  and  processes 
necessary  to  implement  the  behavior  of  the  process  in  the 
Create  MACHINE  DECLARATIONS  DFD  of  Figure  3-15.  The  proc¬ 
esses  for  this  level  of  detail  were  described  in  Section 
3. 5. 3. 3. 

The  level  2  DFD  for  architecture  processing  is  provided 
in  Figure  3-24.  This  DFD  shows  the  subprocess  required  to 
process  a  standard  VHDL  architecture  into  a  JRS  IDAS  styled 
VHDL  architecture . 

The  level  2  DFD  for  validating  conditional  variables  is 
provided  in  Figure  3-25.  The  processes  necessary  for  check¬ 
ing  whether  a  control  variable  is  a  clock_type  or 
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Figure  3-25.  Validate  Conditional  Variables  --  Level  2 

control_type  are  identified,  as  well  as  the  process  that 
reports  to  the  user  if  an  illegal  conditional  variable  is 
found . 

The  level  2  DFD  for  mapping  procedures  is  provided  in 
Figure  3-26.  This  DFD  shows  the  user  interaction  required 
to  perform  mappings  between  JRS  IDAS  and  user-defined  proce¬ 
dures.  It  also  shows  the  process  of  updating  the  source 
files  once  a  mapping  has  been  accomplished. 

3.5.5  Style-V  Data  Dictionary.  The  data  dictionary 
(DD)  for  the  Style-V  system  was  built  as  the  DFDs  were 
constructed.  By  doing  this,  the  meaning  of  each  term  in  the 
context  in  which  it  was  used  was  preserved.  The  DD  gives 
the  item  name  and  a  description  of  the  item. 

Common  notation  and  short  English  phrases  are  used  for 
item  descriptions.  The  common  notation  consists  of  item  or 
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Figure  3-26.  Procedure  Mapping  DFD  --  Level  2 

range  identifiers  and  the  use  of  option  and  repeat 

operators.  An  example  of  a  range  identifier  is  a..z  which  stands 

for  the  small  alphabetic  letters  between  a  and  z  inclusive. 

An  example  of  a  repeat  operator  is  (a..z)2  which  represents 
one  or  more  small  alphabetic  letters .  The  optional  operator 
( I )  is  placed  between  items  to  signify  that  any  of  the  items 
in  the  optional  group  can  be  picked  as  the  value  of  the 
item.  An  example  of  optional  definition  is  (  a  |  b  |  9B  ) , 
signifying  that  the  item  being  defined  is  either  the  letter 
a,  the  letter  b,  or  the  phrase  9B.  Grouping  is  done  inside 
brackets  which  can  be  operated  on  by  repeat  notation,  or 
grouping  can  be  accomplished  by  using  a  different  item 
defined  elsewhere  in  the  DD  as  part  of  the  definition. 

Recursive  and  circular  definitions  should  only  be  used  when 
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an  item  can  go  to  a  null  string  --  the  definition  must 
represent  a  finite  sequence  of  substitutions. 


The  following 
Style-V  Translator 
architecture 

ARCHITECTURES 

bit_type 

character 

component 

COMPONENTS 

conditional 

CONDITIONALS 

conf irm_flag 

count 

COUNT__TOTAL 

declaration 

decl_name 

decl_tail 

ENTITIES 
entity 
extension 
ex tens ion_ ta i 1 
f ile_name 
flag 


alphabetical  listing  is  the  DD  for  the 

:  collection  of  statements  forming  a 

VHDL  architecture 
:  (architecture) Q 

:  type  mark  allowed  in  JRS  styled  VHDL 

:  (a. .zA. -ZO. .9_) 

a  VHDL  design  item 
( component )q 

:  guard  1  sensitivity_list 

:  (conditional) Q 

:  (  Y  I  y  I  N  I  n  ) 

:  integer 

:  a  data  store  to  accumulate  a  total 

:  (name,)Q  (name)  (decl_tail) 

:  name  portion  of  a  declaration 

:  portion  of  a  VHDL  declaration  state 

ment  encompassed  by  " : "  and  " ; " 

:  (entity) 0 

:  a  VHDL  design  unit 

:  (.)  (extension_tail ) 

[  (name)  ( extension )q  ]q 
:  (name)  [extension] q 

:  (character) 
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generic_type 

guard 

heading 

integer 

INTERMEDIATE 

letter 

name 

nondeclaration 

number 

ORIG_ENTITY 

port_list 
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possible_variable 
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a  type  designator  in  a  generic  clause 
conditional  value  for  process  control 
VHDL  code  of  the  form  ARCHITECTURE 
(BEHAVIORAL  |  STRUCTURAL)  of 
ARCHITECTURE_NAME 
(0. 

a  temporary  store  for  process  results 
(a . . zA. . Z) 

(letter  |  number)  ( character )q 
a  group  of  words,  not  a  declaration 
(0. .9) 

high-level  architecture  entity  store 
a  list  of  entity  port  declarations 
a  word  which  may  be  a  constant  name 
a  word,  possibly  a  declaration  part 
a  word  which  may  be  a  variable  name 
signal  values  for  process  control 
nonblank  noncharacter  single  element 
convert  function  for  a  status  type 
a  declaration  for  a  status  variable 
accumulated  value  of  a  data  store 
a  declaration  type  designator 
type  not  mappable  to  JRS  style 
file  storage  of  VHDL  source  code 
[  character  |  special  character  ] 
a  group  /  store  of  zero  or  more  words 
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The  data  dictionary  described  above  provides  a  develop¬ 
er  with  a  frame  of  reference  when  designing  the  modules  to 
implement  the  behaviors  identified  during  analysis.  This 
design  phase  is  covered  in  the  next  chapter. 

3.6  Review 

The  focus  of  Chapter  3  has  been  the  analysis  of  the 
requirements  for  the  Style-V  Translator  to  convert  a  stand¬ 
ard  VHDL  design  into  a  styled  VHDL  design  acceptable  to  the 
JRS  IDAS  system. 

Section  3.1  provided  a  review  of  notations  and  methods 
for  analyzing  a  system.  A  possible  notation  is  a  data  flow 
diagram  (DFD) ,  data  dictionary  (DD),  control  flow  diagram 
(CFD),  entity- relationship  diagram  (ERD) ,  or  some  variant  of 
these.  The  analysis  methods  which  use  these  notations  are 
Structured  Requirements  Definition,  Structured  Analysis  and 
Design  Technique,  Structured  Analysis  and  System  Specifica¬ 
tion,  Modern  Structured  Analysis,  Problem  Statement  Language 
/  Problem  Statement  Analyzer  (PSL/PSA)"^^,  and  Object-Orient¬ 
ed  Problem  Analysis.  Two  other  simpler  analysis  methods 
used  for  small  problems  are  the  method  of  listing  inputs  and 
outputs  and  the  method  of  listing  major  functions. 

Section  3.2  discussed  the  choice  of  Modern  Structured 
Analysis  as  the  method  for  the  analysis  of  Style-V.  Basi¬ 
cally,  the  translations  and  mappings  done  by  Style-V  are 
functionally  intensive,  so  a  functional  decomposition  was 
chosen . 
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Section  3 . 3  provided  a  starting  place  to  consider  the 
functions  of  a  translator  system.  The  lexical,  syntactic, 
and  semantic  processes  which  compose  a  translation  system 
were  described.  Armed  with  the  knowledge  of  the  functional¬ 
ity  required  of  a  translator  and  knowing  that  the  input  was 
already  syntactically  correct,  it  was  then  possible  to 
ensure  the  main  processes  of  Style-V  provided  lexical  and 
semantic  processing  capabilities.  Each  of  the  main  Style-V 
processes  has  a  lexical  function  which  reads  input  files  and 
forms  tokens  understandable  to  the  remaining  functions  of 
the  process .  The  functions  of  the  processes  that  do  most  of 
the  work  of  Style-V  (like  converting  types)  are  semantic 
functions  as  they  modify  the  input  files  but  in  a  way  that 
maintains  the  original  meaning  --as  much  as  possible. 

Section  3 . 4  was  a  detailed  look  at  the  problem  faced  by 
Style-V.  The  differences  between  the  VHDL  subset  defined  by 
JRS  and  standard  VHDL  were  compared.  The  differences  could 
be  characterized  as  type,  declaration,  structural,  state¬ 
ment,  and  other.  An  example  stylized  machine  was  discussed 
and  lessons  learned  from  the  example  were  provided.  Section 
3.4  ended  with  a  discussion  of  the  limitations  of  the  JRS 
style  of  VHDL  and  the  difficulties  posed  by  these  limita¬ 
tions  . 

Finally,  Section  3.5  was  the  Modern  Structured  Analysis 
of  the  Style-V  system.  It  started  with  a  view  of  the  system 
context.  Then,  the  external  events  affecting  the  system 
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were  identified.  Next,  the  Style-V  processes  which  respond¬ 
ed  to  the  external  events  were  documented  at  a  high  level  of 
abstraction.  The  next  step  was  to  decompose  and  level  the 
data  flow  diagrams  into  a  more  detailed  representation  of 
the  system.  During  this  leveling  process,  the  true  magni¬ 
tude  of  the  Style-V  creation  task  was  realized  and  the 
thesis  was  scoped  to  concentrate  on  four  of  the  six  main 
processes  of  Style-V.  During  the  creation  of  the  data  flow 
diagrams,  a  data  dictionary  was  produced  to  document  the 
data  moving  in  the  system. 

Now  that  the  Style-V  Translator  system  has  been  ana¬ 
lyzed,  Chapter  4  will  document  the  manual  demonstrations  of 
the  concepts  described  above.  The  processes  of  converting 
VHDL  CASE  statements  to  IF  statements,  converting  free -form 
VHDL  types  into  the  more  restricted  JRS  IDAS  types,  convert¬ 
ing  multiple  process  architectures  into  single  process 
architectures,  and  converting  user-defined  procedures  into 
JRS  IDAS  procedures  will  be  demonstrated. 
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ly.  Demonstration  of  Concept 


4.0  introduction 

It  is  not  possible  to  complete  an  implementation  of 
Style-V  during  one  thesis  cycle  --  the  problem  is  just  too 
large.  Therefore,  instead  of  following  Chapter  3  with  a 
design  chapter,  Chapter  4  provides  documentation  of  manual 
implementations  of  some  of  the  mappings  required  for  Style- 
V.  The  manual  demonstrations  show  the  feasibility  of  the 
concepts  derived  during  the  analysis  described  in  Chapter  3 . 
The  implementation  of  other  Style-V  processes  will  use 
similar  techniques  to  those  this  chapter  describes.  Also, 
this  thesis  effort  has  laid  the  ground  work  for  any  effort 
which  would  further  implement  Style-V. 

Section  4.1  discusses  the  selection  of  concepts  for 
manual  implementation .  Section  4 . 2  provides  a  description 
of  a  manual  implementation  of  the  mappings  using  portions  of 
the  VHDL  design  of  a  substantial  integrated  circuit  now 
being  developed  by  the  Air  Force  --  the  FPASP.  Section  4.3 
discusses  the  lessons  learned  from  the  manual  implementation 
process.  Finally,  Section  4.4  provides  a  review  of  this 
chapter . 

4.1  Selection  of  Concepts 

Four  of  the  mappings  were  chosen  for  manual  demonstra¬ 
tion  of  the  translation  concepts  for  mapping  standard  VHDL 
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to  the  JRS  subset.  The  concepts  of  CASE  statement  conver¬ 
sion,  type  conversion,  architecture  conversion,  and  proce¬ 
dure  mapping  were  chosen  as  being  representative  of  the 
tasks  of  Style-V.  Demonstration  of  these  mappings  shows  the 
unfeasibility  of  a  fully  automated  implementation  and  demon¬ 
strates  that  only  a  partially  automated  solution  is 
possible.  The  remainder  of  this  section  describes  the  ra¬ 
tionale  for  choosing  these  mappings. 

CASE  statement  conversion  was  chosen  as  one  of  the 
tasks  for  manual  implementation  due  to  the  prevalence  of 
CASE  statements  in  VHDL  designs.  Conversion  of  CASE  state¬ 
ments  also  affects  the  implementation  of  behaviors  as  de¬ 
scribed  in  the  JRS  Style  Guide,  since  system  behaviors  are 
to  be  captured  in  behavioral  IF  statements  (VHDL  Style, 
1989:11,13).  The  conversion  of  CASE  statements  also  repre¬ 
sents  a  category  of  the  translation  tasks  dealing  with  local 
modifications  of  input  files  --  global  knowledge  of  the 
system  is  not  required.  Other  mappings  falling  in  this 
"local  look"  category  are  converting  modes  BUFFER  and  LINK¬ 
AGE  to  mode  INOUT,  using  GUARD  and  SENSITIVITY  LISTS  to 
build  WAIT  statements,  moving  signal  delay  to  an  AFTER 
clause,  and  removing  structural  architecture  signal  delay. 

Another  mapping  required  to  translate  standard  VHDL 
into  JRS  styled  VHDL  is  type  conversion.  JRS  allowed  types 
are  quite  limited  when  compared  with  the  rich  type  struc¬ 
tures  allowed  by  standard  VHDL.  The  ability  to  map  user- 
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defined  types  which  use  bit  and  bit_vector  logic  is  basical¬ 
ly  a  direct  translation  to  the  JRS  bit  types.  However,  most 
VHDL  designs  use  multilevel  logic  when  representing  modern 
integrated  circuits .  This  multilevel  logic  is  usually 
represented  by  a  base  type  which  is  an  enumerated  type 
showing  the  representation  of  signal  states.  An  example  is 
the  use  of  the  enumerated  type  ('O',  '1',  'X',  'Z')  to 
represent  the  states  zero,  one,  don't  care,  and  high  imped¬ 
ance  . 

Successful  mapping  of  these  multilevel  logic  types  to 
JRS  bit  types  represented  quite  a  challenge.  Tasks  similar 
to  the  type  conversion  task  but  not  part  of  the  FPASP  manual 
demonstration  are  generic  clause  conversion  and  status  type 
conversion . 

Architectural  conversion  from  multiple  concurrent 
statement  architectures  (those  with  block  or  multiple  proc¬ 
ess  statements)  to  single  process  architectures  is  described 
and  the  manual  demonstration  documented.  The  ability  to 
perform  architecture  conversion  was  dependent  on  having  a 
global  view  of  an  entire  architecture  and  the  entity  which 
defined  the  interfaces  of  the  architecture.  From  these,  new 
lower  level  entities  and  architectures  could  be  constructed. 
The  goal  of  architecture  conversion  was  to  maintain  a  system 
view  of  the  architecture  which  was  the  same  as  the  original 
architecture.  To  obtain  this  view,  the  multiple  internal 
processes  had  to  be  converted  to  single  process 
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subarchitectures  as  components  of  a  new  architecture  with 
the  same  external  view  as  the  original.  Since  the  problem 
of  mapping  multiple  concurrent  statement  architectures  to 
single  process  architectures  deals  with  limited  global 
knowledge,  it  is  somewhat  similar  to  the  problems  of  gather¬ 
ing  machine  declarations  into  one  file  and  matching  compo¬ 
nents  to  the  entities  they  instantiate  -  -  two  problems  not 
chosen  for  manual  implementation  using  the  FPASP. 

Procedure  mapping  was  chosen  due  to  the  criticality  of 
the  requirement  to  be  able  to  map  user- defined  procedures  to 
JRS  IDAS  defined  procedures.  This  thesis  worked  toward 
developing  a  translator  for  the  microcode  generation  portion 
of  the  JRS  IDAS.  The  microcode  generator  of  the  IDAS  does 
not  recognize  any  user-defined  procedures,  but  can  only 
generate  microcode  for  behaviors  modeled  using  JRS  provided 
procedures.  Therefore,  it  is  absolutely  critical  to  map 
user-defined  functions  and  procedures  to  JRS  provided  proce¬ 
dures  .  The  ability  to  map  functions  required  a  high  level 
knowledge  of  the  logic  of  the  functions  being  mapped.  Other 
than  the  transformation  of  types,  which  is  also  included  as 
a  manual  implementation,  no  other  mappings  are  similar  to 
the  task  of  mapping  procedure  calls. 

4.2  Manual  implementations 

This  section  provides  a  detailed  explanation  of  the 
manual  implementation  of  the  four  mappings  described  in 
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Section  4.1.  Section  4.2.1  describes  the  CASE  statement 
conversion  using  the  FPASP  upper  data  path  as  an  example. 
Section  4.2.2  describes  the  type  translations  carried  out  on 
the  types  of  the  FPASP.  Section  4.2.3  describes  the  archi¬ 
tecture  conversion  process  using  the  same  upper  data  path  as 
used  for  the  CASE  statement  conversion.  Finally,  Section 
4.2.4  describes  the  procedure  mappings  carried  out  using  the 
ALU  functions  description  of  the  upper  data  path  of  the 
FPASP. 

4.2.1  CASE  Statement  Conversion.  Since  a  VHDL  CASE 
statement  is  a  more  compact  notation  to  perform  the  function 
of  an  IF-THEN-ELSIF-ELSE  structure,  conversion  of  the  CASE 
statement  to  an  IF  statement  is  not  difficult.  All  the 
information  to  form  the  IF  statements  is  readily  available 
in  the  CASE  statement  structure. 

Consider  the  general  form  of  the  CASE  statement  in 
Figure  4-1,  and  compare  it  with  an  equivalent  IF  statement 
in  Figure  4-2.  The  conditional  variable  (cond_var)  of  the 
CASE  statement  is  compared  against  the  conditional  value 
(cond_val)  in  the  WHEN  portions  of  the  CASE  statement  to 
determine  which  alternative  is  executed.  Using  an  IF-THEN- 
ELSIF-ELSE  structure,  the  cond_var  is  compared  with  the 
cond_val  until  it  is  equal  and  that  determines  which  VHDL 
statements  are  executed.  Therefore,  the  only  knowledge 
required  to  translate  from  CASE  to  IF-THEN-ELSIF-ELSE  struc¬ 
ture  consists  of  the  conditional  variable,  the  conditional 
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values,  and  the  VHDL  statements  which  are  executed  for  a 
given  conditional  value. 


CASE  cond  var  IS 


WHEN  cond_vall  =>  VHDL  statements 
WHEN  cond_val2  =>  VHDL  statements 
WHEN  cond  val3  =>  VHDL  statements 


I  WHEN  cond_valn  =>  VHDL  statements  1 

I  WHEN  others  =>  VHDL  statements  j 

I  END  CASE;  | 

I  I 

\ - - - - - / 

Figure  4-1.  General  CASE  Statement  Structure 

The  documentation  provided  by  JRS  on  the  style  of  VHDL 
acceptable  to  IDAS  did  not  clearly  describe  the  allowed 
structure  for  an  IF  statement.  The  approach  of  this  thesis 
was  to  convert  CASE  statements  to  the  IF-THEN-ELSIF-ELSE 
structure  and  run  some  translated  code  through  the  IDAS  to 
verify  that  was  an  acceptable  structure.  Should  the  IDAS 
have  rejected  the  IF-THEN-ELSIF-ELSE  structure,  it  would 
have  been  a  simple  matter  to  change  the  translator  to 
produce  only  IF-THEN  statements  as  the  translation  of  the 
VHDL  CASE  statement.  Since  the  portion  of  the  IDAS  required 
for  this  thesis  did  not  work,  it  was  not  possible  to  vali¬ 
date  the  CASE  to  IF  conversion  hypothesis. 

The  process  of  generating  only  IF-THEN  structures 
instead  of  IF-THEN-ELSIF-ELSE  structures  would  simply  entail 
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IF  cond_var  =  cond_vall  THEN 
VHDL  statements 

ELSIF  cond_var  =  cond_val2  THEN 
VHDL  statements 

ELSIF  cond_var  =  cond_val3  THEN 
VHDL  statements 


ELSIF  cond_var  =  cond_valn  THEN 
VHDL  statements 

ELSE 

VHDL  statements 
END  IF; 


\  - - / 

Figure  4-2.  General  IF  Statement  Structure 


generating  an  END  IF  followed  by  an  IF  each  time  an  ELSIF  or 
an  ELSE  would  be  generated.  Following  the  IF,  should  a 
conditional  value  be  present,  the  condition  of  the  IF  would 
check  the  equality  of  the  cond_var  and  the  current  cond_val. 
On  the  other  hand,  should  no  cond_val  be  present  (processing 
the  ELSE  clause),  the  IF  condition  would  be  to  check  if  the 
condvar  was  not  equal  to  any  of  the  conditional  values  used 
in  the  previous  IF  statements  during  the  processing  of  the 
current  CASE  statement.  This  means  a  simple  list  of  the 
conditional  values  must  be  maintained  if  CASE  statements  are 
translated  to  IF-THEN  statements  only.  See  Figure  4-3  for  a 
simple  example. 

The  CASE  to  IF-THEN-ELSIF-ELSE  process  was  the  only 
Style-V  process  taken  past  the  analysis  and  preliminary 
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CASE  X  IS 

WHEN  1  =>  statements 
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statements  1 
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END  IF; 
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IF  (X  =  2)  THEN 
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1 

statements  2 

1 

1 

END  IF; 

1 

1 

IF  not  ( (X  =  1)  or  (X  =  2) ) 

THEN 

1 

1 

statements  3 

1 

1 

1 

\  — 

END  IF; 

1 

1 

- _ / 

Figure  4-3.  CASE  to  IF-THEN  Example 


design  phases  to  actual  implementation.  This  module  suc¬ 
cessfully  converted  the  CASE  statements  of  the  architectures 
extracted  from  the  upper  data  path  of  the  FPASP  design. 

The  CASE_to_IF  module  was  run  on  the  nev  architectures 
UPPER_ REGISTERS,  UPPER_ALU_SHIFTER,  FUNCTION_ROM,  and  LITER- 
AL_INSERTER  which  were  created  by  the  architecture  conver¬ 
sion  process  (described  in  Section  4.2.3).  However,  as 
noted  before,  these  conversions  are  orthogonal  and  the  same 
results  would  occur  should  the  CASE  to  IF  conversion  be  done 
before  the  creation  of  new  architectures. 

Implementation  of  the  CASE_to_IF  module  produced  suc¬ 
cessful  results.  Sample  results  from  running  it  against 
FPASP  code  comprise  Section  1  of  Appendix  C.  The  CASE_to_IF 
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pseudo  code,  C  code,  and  tests  and  results  are  located  in 
Appendix  D. 

4.2.2  Type  Conversion.  As  described  in  Chapter  3, 
type  conversion  posed  several  challenges.  The  JRS  types  are 
limited  to  bit  types  --  those  based  on  bit  logic  consisting 
of  I's  and  O's.  This  restriction  does  not  allow  types  that 
represent  multilevel  logic,  such  as  the  enumerated  type 
BUS_BIT  used  by  the  FPASP  to  represent  four-level  logic. 

The  type  BUS_BIT  uses  '0'  to  represent  zero,  '1'  to  repre¬ 
sent  one,  'X'  to  represent  don't  care,  and  'Z'  to  represent 
high  impedance. 

Package  and  package  body  FPASP4_2_TyPEDEF  are  included 
in  Appendix  B  and  contain  the  type  definitions  for  the  FPASP 
VHDL  dfc.'^cription .  This  code  was  examined  and  an  algorithm 
devised  to  translate  the  four-level  logic  of  the  FPASP  to  a 
two -level  (bit)  logic  representation.  The  translated 
FPASP4_2_TYPEDEF  package  specification  and  body  are  located 
in  Appendix  C . 

The  first  review  of  the  declarations  package 
FPASP4_2_TYPEDEF  revealed  that  most  of  the  types  were  de¬ 
fined  with  a  base  type  of  BUS_BIT.  As  described  above, 
BUS_BIT  was  an  enumerated  type  ('X','0','1','Z').  Since 
this  type  of  enumerated  type  is  not  allowed  in  the  JRS  IDAS 
style  of  VHDL,  a  conversion  to  a  bit  type  was  necessary. 

Since  only  'O's  and  'I's  are  allowed  by  the  IDAS,  the 
first  approach  considered  was  to  convert  'X'  and  'Z'  to 
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either  '0'  or  '1'.  The  problem  with  this  type  of  conversion 
is  that  some  of  the  functions  defined  for  the  FPASP  depend 
on  the  ability  to  model  multilevel  logic.  A  further  discus¬ 
sion  of  this  problem  is  in  Section  3. 4. 1.1  and  a  sample 
section  of  procedure  code  that  would  always  cause  "incor¬ 
rect"  procedure  execution  was  provided  in  Figure  3-7. 

Since  a  simplistic  conversion  was  not  possible,  another 
method  was  necessary.  The  next  step  was  to  consider  repre¬ 
senting  each  bit  of  the  BUS_BIT  type  by  a  bit_vector  of 
length  two .  A  ' 0 '  would  be  represented  by  the  bit_vector 
"00",  a  '1'  by  "01",  a  'X'  by  "10",  and  a  'Z'  by  "11".  The 
translation  of  any  type  with  a  base  type  of  BUS_BIT  would 
then  entail  using  multilevel  bit  vectors.  For  example,  the 
BUS_BIT_VECT0R  "OIXZ"  would  be  represented  as  a  vector  of 
bit  vectors  ( "00" , "01" , "10" , "11" ) .  This  type  of  translation 
may  work  for  some  tools;  however,  the  JRS  IDAS  Move  proce¬ 
dure  which  is  used  to  move  data  around  a  design  can  only 
process  bit_vectors  --no  multidimensional  bit  vectors. 

Knowing  that  the  IDAS  required  data  to  be  in  the  form 
of  bit_vectors,  the  next  logical  step  was  to  consider  using 
two  bits  to  represent  one  logical  bit.  Using  this  approach, 
a  0  would  be  represented  by  00,  a  1  by  01,  a  X  by  10,  and  a 
Z  by  11.  Then,  the  example  BUS_BIT_VECTOR  "OIXZ"  would 
become  the  BIT_VECTOR  "00011011".  This  solution  was  suit¬ 
able  for  the  IDAS  MOVE  procedures.  However,  another  concern 
arose.  The  other  IDAS  procedures  which  would  replace  ALU- 
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type  operations  will  use  bit  vectors  from  the  system  and 
produce  results  from  them,  but  these  procedures  expect  true 
two -level  logic  bit  vectors,  so  a  conversion  function  must 
translate  the  two-level  logic  representation  of  four-level 
logic  into  true  two -level  logic  before  entering  any  of  the 
ALU- type  IDAS  procedures  and  back  again  to  four-level  logic 
represented  in  two -level  logic  after  the  procedures  to 
maintain  compatibility  with  the  rest  of  the  FPASP  chip. 

To  lessen  the  amount  of  "name"  changing  the  translator 
would  do,  the  base  type  name  was  maintained  and  the  new 
representation  for  the  type  introduced.  Since  representing 
the  four -level  logic  elements  as  bit  vectors  would  cause 
IDAS  Move  problems,  the  BUS_BIT  type  became  ('O',  '1')  --  a 
type  compatible  with  type  BIT.  Should  this  have  not  been 
acceptable  to  IDAS,  changing  the  type  BUS_BIT  to  subtype 
BUS_BIT  of  BIT  would  have  worked  as  an  alternate  option  and 
not  affected  the  remaining  translations. 

Now,  since  each  BUS_BIT  in  the  BUS_BIT_VECTORS  is 
represented  by  two  bits,  the  specified  length  of  each 
BUS_BIT_VECTOR  declaration  must  be  doubled.  For  example, 
BUS_BIT_VECT0R(31  downto  0)  would  become  BUS_BIT_VECTOR( 63 
downto  0)  and  BUS_BIT_VECTOR( 1  to  7)  would  become 
BUS_BIT_VECTOR( 1  to  14).  In  general,  the  new  lower  index 
has  the  same  value  as  the  original  lower  index  and  the 
formula  for  calculating  the  upper  index  is : 

Upperindex  :=  Highindex  +  High_Index  -  Lowindex  +  1. 
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The  decision  on  which  index  to  change  is  determined  by 
the  word  between  the  indexes.  If  the  word  "downto"  is 
between  the  indexes,  the  left  index  is  changed,  otherwise 
the  right  index  is  changed. 

Another  concern  is  constant  declarations .  Not  only 
does  the  index  range  need  adjustment,  but  the  literal  repre¬ 
senting  the  constant  must  be  adjusted  also.  However,  since 
the  logical  bit  of  each  true  bit  is  simply  a  double  bit,  the 
replacement  can  be  made  by  replacing  each  bit  of  a  constant 
literal  with  the  corresponding  double  bit.  For  example,  the 
constant  literal  "ZZXXIO"  would  become  "111110100100". 

From  the  above  discussion,  it  is  easy  to  see  that  only 
local  knowledge  is  required  to  change  type  declarations . 

Once  the  base  type  is  identified  and  changed,  changing  the 
other  declarations  is  simply  a  matter  of  text  replacement  or 
index  calculation  and  replacement.  Changing  procedure  and 
function  declarations  is  done  in  the  same  way.  However, 
within  procedure  and  function  bodies,  the  calculations  and 
modifications  are  more  difficult. 

Not  only  do  loop  ranges  need  to  be  calculated  in  a 
similar  way  to  declaration  ranges,  but  the  assignment  logic 
inside  a  loop  must  account  for  assigning  two  bits  instead  of 
one.  For  example,  if  a  pretranslation  assignment  statement 
was : 

XX ( I )  : «  ' 1 ' , 
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the  new  assignment  statement  would  be: 

XX(I*2  to  1*2+1)  :=  "01", 
or  possibly: 

XX (1*2+1  downto  1*2)  :=  "01". 

Also,  the  logic  of  the  loop  would  need  to  be  modified  to 
skip  execution  of  the  loop  on  every  other  pass  because  two 
bits  were  processed  on  the  previous  pass.  Figure  4-5  pro¬ 
vides  an  example  of  the  FPASP  code  and  the  modified  loop 
resulting  from  translation. 

Another  consideration  evident  from  Figure  4-5  is  how  to 
translate  simple  constructs  into  more  complex  constructs. 

The  calculation  TEMP(I)  :=  A(I)  and  B(I)  of  Figure  4-5  was 
simple  due  to  the  definition  of  the  "and"  operator  for  two 
single  element  BUS_BITs.  However,  since  the  translation  now 
uses  two -element  BUS_BIT_VECTORS  to  represent  an  actual  bit, 
the  previous  "and"  function  which  performed  an  and  of  two 
BUS_BITs  became  one  with  two  parameters  of  type 
BUS_BIT_VECTOR  (1  downto  0)  and  a  return  type  of 
BUS_BIT_VECTOR.  However,  this  caused  a  compile  error  in  the 
VHDL  analyzer  due  to  an  ambiguous  overloading  of  this  "and" 
function  with  the  more  general  "and"  function  with 
BUS_BIT_VECTOR  parameters  and  return  type. 

The  solution  taken  in  the  manual  implementation  was  to 
expand  the  more  general  "and"  function  to  perform  all  calcu¬ 
lations  necessary  to  produce  the  "and"  result.  The  truth 
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table  from  the  FPASP  design  which  had  to  be  implemented  for 
the  "and"  operation  is  provided  in  figure  4-4. 


/ 


\ 


I  OPERAND  2  BIT  | 

I  / - \  , 

I  I  AND  I  X  I  Z  I  0  I  1  I  1 

I  I - I  I 

I  I  X  I  X  X  0  X  I  I 

I  I - 1  I 

I  OPERAND  1  BIT  |  Z  |  X  X  0  X  |  | 

I  I - ,  I 

I  I  0  I  0  0  0  0  I  I 

I  I - I  I 

I  1  1  I  X  X  0  1  I  I 

I  \ - - - /  I 

I  I 

\ - / 


Figure  4-4.  FPASP  General  "and"  Truth  Table 


Another  approach  which  would  be  simpler  to  implement 
for  Style-V  would  be  to  rename  the  "and"  function  which  had 
parameters  BUS_BIT_VECTOR  (1  downto  0)  and  to  call  the  newly 
named  function  from  the  now  simplified  translation  of  the 
general  "and"  function.  Figure  4-6  provides  the  more  sim¬ 
plified  translation  of  the  general  "and"  function,  and 
Figures  4-7  and  4-8  show  the  translation  of  the  BUS_BIT 
function  to  the  BUS_BIT_VECTOR  (1  downto  0)  function  is 
basically  a  one-for-one  textual  substitution  --an  easy 
translation . 
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- \ 

I 

BEFORE  I 

I 

function  "and" (A,  B  :  BUS_BIT_VECTOR)  | 

return  BUS_BIT_VECTOR  is  I 

variable  TEMP  :  BUS_BIT_VECTOR( 31  downto  0);  | 

begin  I 

for  I  in  A 'LOW  to  A' HIGH  loop  | 

TEMP(I)  :=  A(I)  and  B(I);  | 

end  loop ;  ( 

return  TEMP (A' RANGE) ;  1 

end  "and";  I 


I  AFTER  I 

I  1 

I  function  "and" (A,  B  :  BUS_BIT_VECTOR)  | 

I  return  BUS_BIT_VECTOR  is  | 

I  variable  TEMP  :  BUS_BIT_VECTOR( 63  downto  0);  1 

I  variable  SKIP  :  BIT  :=  'O';  | 

I  I 

1  begin  1 

I  for  I  in  A'HIGH-A'LOW  downto  0  loop  1 

I  if  SKIP  =  '0'  then  | 

I  if  (A(I  downto  I-l)  =  "00")  or  | 

1  (B(I  downto  I-l)  =  "00")  then  j 

I  TEMP{I  downto  I-l)  :=  "00";  | 

I  elsif  (A(I  downto  I-l)  =  "11")  or  1 

I  (A(I  downto  I-l)  =  "10")  then  | 

1  TEMP (I  downto  I-l)  :=  "10";  1 

I  elsif  (A(I  downto  I-l)  =  "01")  and  j 

I  (B(I  downto  I-l)  =  "01")  then  | 

I  TEMP(I  downto  I-l)  :=  "01";  j 

I  else  TEMP (I  downto  I-l)  :=  "10";  j 

I  end  if;  j 

I  SKIP  | 

j  else  j 

I  SKIP  :=  'O';  1 

1  end  if;  j 

j  end  loop;  j 

I  return  TEMP(A'high-A'low  downto  0);  1 

I  end  "and";  I 

\-- - - - - / 

Figure  4-5.  Sample  "Hard"  Loop  Translation 
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BEFORE 


function  "and" (A,  B  :  BUS_BIT_VECTOR) 

return  BUS_BIT_VECTOR  is 
variable  TEMP  :  BUS_BIT_VECT0R(31  downto  0); 
begin 

for  I  in  A 'LOW  to  A' HIGH  loop 

TEMP(I)  :=  A{I)  and  B(I); 

end  loop; 

return  TEMP (A' RANGE) ; 
end  "and"; 


AFTER 

function  "and" (A,  B  :  BUS_BIT_VECTOR) 

return  BUS_BIT_VECTOR  is 
variable  TEMP  :  BUS_BIT_VECTOR(63  downto  0); 
variable  SKIP  :  BIT  :=  'O'; 

begin 

for  I  in  A'HIGH-A'LOW  downto  0  loop 
if  SKIP  =  '0'  then 

TEMP(I  downto  I-l)  := 

A(I  downto  I-l)  and2  B(I  downto  I-l); 
SKIP  :=  '1'; 
else 

SKIP  :=  'O'; 
end  if; 


end  loop; 

return  TEMP (A' high- A' low  downto  0); 
end  "and"; 


Figure  4-6.  Simplified  "and"  Translation 
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BEFORE 


function  "and" (A,  B  :  BUS_BIT)  return  BUS_BIT  is 
begin 

case  A  is 

when  'X'  => 
if  B  =  '0' 

then  --  'and'  is  dependent  on  B. 
return  ' 0 ' ; 
else  --  Undefined. 

return  ' X ' ; 
end  if; 
when  'Z'  => 
if  B  =  '0' 

then  --  'and'  is  dependent  on  B. 
return  'O'; 
else  --  Undefined. 

return  'X'; 
end  if; 

when  '0'  =>  return  'O'; 

--  Doesn't  matter  what  B  is. 
when  '1'  =>  --  'and'  is  dependent  on  B. 

if  B  -  'Z' 

then  --  Undefined, 
return  ' X ' ; 

else 

return  B; 
end  if; 
end  case; 
end  "and"; 


Figure  4-7. 


and"  With  BUS_BIT  Type 


/■ 


•\ 


\- 


AFTER 

function  "and2"(A,  B  :  BUS_BIT_VECTOR( 1  downto  0)) 

return  BUS_BIT_VECTOR  is 

begin 

case  A  is 

when  "10"  => 
if  B  =  "00" 

then  --  'and'  is  dependent  on  B. 
return  "00"; 
else  --  Undefined. 

return  "10"; 
end  if; 
when  "11"  => 
if  B  =  "00" 

then  --  'and'  is  dependent  on  B. 
return  "00"; 
else  --  Undefined. 

return  " 10 " ; 
end  if; 

when  "00"  =>  return  "00"; 

-  -  Doesn ' t  matter  what  B  is . 
when  ”01"  =>  --  'and'  is  dependent  on  B. 

if  B  =  "11" 

then  --  Undefined, 
return  " 10 " ; 

else 

return  B; 
end  if; 
end  case; 
end  "and2"; 


Figure  4-8.  "and"  With  BUS_BIT_VECTOR  (1  downto  0)  Type 


■/ 


Some  type  of  data  structure  which  contained  the  origi¬ 
nal  declaration  and  the  translated  declaration  would  need  to 
exist  to  facilitate  the  renaming  of  a  less  general  function 
as  described  above.  As  the  translator  worked  through  a 
file,  it  would  not  know  a  more  general  function  was  coming 
which  would  have  a  type  conflict  with  a  newly  translated 
function.  A  table  implemented  as  a  linked  list  of  two-field 
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records  would  serve  this  purpose.  The  link  list  would 
provide  quick  order  1  time  storage  of  new  data,  and  since 
the  number  of  procedures  would  be  relatively  small  for  most 
designs  (n  <  1000),  the  order  n  search  time  required  to  find 
a  less  general  function  would  not  be  significant.  In  fact, 
since  most  "like  named"  functions  generally  occur  in  the 
same  vicinity  of  a  design,  and  since  the  less  general  func¬ 
tion  is  usually  defined  before  the  more  general  ones,  the 
search  would  be  much  less  than  n  on  average,  though  the 
worst  case  would  still  be  on  the  order  of  n. 

In  summary,  the  type  conversion  process  required  to 
translate  the  FPASP  with  four-level  BUS_BIT  representation 
into  bit  logic  required  implementing  a  translation  scheme  to 
use  bit  logic  to  represent  four- level  logic,  translating  all 
declarations  using  the  new  representation,  and  translating 
any  functions  or  procedures  operating  on  the  types  of  the 
system  to  use  the  new  bit  logic  types.  Some  translations, 
such  as  declaration  ranges  and  literal  values  was  straight 
forward  and  consisted  mainly  of  textual  substitution.  Other 
translations,  such  as  function  logic  (for  example,  loops), 
was  more  difficult  and  required  knowledge  of  how  using  two 
bits  to  represent  one  actual  bit  affected  the  system. 

4.2.3  Architecture  Conversion.  Besides  type  restric¬ 
tions,  another  major  restriction  of  JRS  IDAS  for  VHDL  de¬ 
signs  is  the  requirement  to  have  only  one  process  statement 
for  a  behavioral  architecture.  In  standard  VHDL,  a  designer 
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can  model  any  number  of  concurrent  processes  and  blocks  in 
an  architecture. 

Section  3. 4. 1.3  discussed  structural  differences  be¬ 
tween  JRS  IDAS  styled  VHDL  and  standard  VHDL,  including  a 
discussion  of  architectural  differences.  A  detailed  discus¬ 
sion  of  the  algorithm  for  converting  a  multiple  concurrent 
statement  architecture  to  multiple  single  process  architec¬ 
tures  was  given  in  Section  3. 5. 3. 4.  This  section  provides  a 
review  of  an  implementation  of  the  architecture  conversion 
algorithm  on  one  entity  and  architecture  of  the  FPASP. 

The  FPASP4_UDATAPATH  entity  and  architecture  were 
chosen  for  decomposition  because  they  presented  most  of  the 
translation  challenges  identified  in  the  architecture  con¬ 
version  algorithm.  For  the  FPASP4_UDATAPATH  entity,  one 
port  had  mode  BUFFER,  which  is  not  an  allowed  mode  for  JRS 
IDAS  styled  VHDL.  The  entity  had  a  generic  clause,  but  the 
only  type  used  in  the  generic  clause  was  INTEGER,  so  no 
translation  was  necessary  for  the  generic  types.  Finally, 
several  BUS  types  were  defined  as  entity  ports. 

Challenges  represented  by  the  FPASP4_UDATAPATH  archi¬ 
tecture  were  aliases  of  slices  of  entity  ports,  statements 
outside  of  any  process  or  block,  and  processes  within 
blocks.  The  successful  manual  conversion  of  this  architec¬ 
ture  shows  the  feasibility  of  converting  architectures  in 
general  using  the  algorithm  defined  in  this  thesis.  Refer 
to  Appendix  B  for  the  original  FPASP4_UDATAPATH  entity  and 
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architecture  descriptions  and  Appendix  C  for  the  translated 
FPASP4_UDATAPATH  entity  and  architectures . 

The  conversion  process  began  by  determining  which 
statements  did  not  fall  within  any  process  or  block.  These 
statements  were  set  aside  to  be  used  in  the  final  architec¬ 
ture  which  instantiated  all  the  subarchitectures  created  in 
the  next  steps .  These  statements  were  saved  to  put  in  a 
begin -end  structure  for  the  new  FPASP4_UDATAPATH  architec¬ 
ture.  This  completed  a  first  pass  of  the  FPASP4  UDATAPATH 
architecture . 

The  second  conversion  step  was  to  convert  the  block 
statements  into  process  statements.  Since  each  block  con¬ 
sisted  of  a  process  statement,  this  was  a  simple  matter  of 
performing  the  following  thirteen  steps: 

1.  scanning  for  the  block  statement, 

2.  scanning  the  block  guard  fif  any), 

3.  saving  the  guard  for  latter  use, 

4.  removing  the  guard  statement, 

5.  scanning  for  the  process  statement, 

6.  scanning  the  process  sensitivity  list  (if  any), 

7.  saving  the  sensitivity  list  for  latter  use, 

8.  removing  the  sensitivity  list  from  the  process 

statement, 

9.  passing  through  any  declarations, 

10.  scanning  the  "begin"  for  the  process, 

11.  creating  and  inserting  a  WAIT  statement  for  the 
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process  with  an  UNTIL  clause  for  the  saved  guard  condi 
tions  and  an  ON  clause  for  the  saved  sensitivity  list, 

12.  passing  all  information  through  until  an  "end 
process"  phrase  was  scanned, 

13.  finally,  deleting  the  "end  block"  phrase  which 
followed  the  "end  process"  phrase. 

The  above  processing  would  continue  for  the  remainder 
of  the  FPASP4_UDATAPATH  architecture.  This  processing 
comprises  the  second  pass  through  the  FPASP4_UDATAPATH 
architecture.  The  results  of  these  second  step  actions 
would  be  a  sequence  of  process  statements  with  a  WAIT  state 
ment  with  UNTIL  or  ON  clauses  as  the  first  statement  of  the 
process  --a  requirement  of  JRS  styled  VHDL.  Figure  4-9 
provides  an  abbreviated  representation  of  the  results  of 
this  process . 

Once  the  block  and  process  statements  of  the 
FPASP4_UDATAPATH  were  converted  to  a  sequence  of  process 
statements  with  the  JRS  required  WAIT  statement,  new  enti¬ 
ties  for  each  process  statement  were  created.  The  name  of 
each  of  these  new  entities  could  have  been  any  legal  name 
allowed  by  VHDL  which  did  not  duplicate  existing  names  in 
the  design,  but  using  labels  of  block  or  process  statements 
of  the  original  architecture  made  the  printed  output  of  the 
translation  easier  to  follow. 

To  form  the  ports  of  each  entity,  each  process  state¬ 
ment  was  scanned  to  determine  which  ports  (or  aliases  of 
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. — - - - \ 

Architecture  BEHAVIOR  of  FPASP4_UDATAPATH  is  | 

I 

declarations  | 

alias  X  :  . . .  j 

alias  y  :  . . .  j 

begin  j 

UPPER_REGISTERS:  process  | 

begin  1 

WAIT  UNTIL  guardl  ON  sensitivity  listl;  j 

{statements}  j 

end  process;  1 

UPPER_ALU_SHIFTER:  process  | 

begin  j 

WAIT  UNTIL  guard2  ON  sensitivity  list2  I 

{ statements }  j 

end  process;  j 

UINSERT:  process  j 

begin  j 

WAIT  UNTIL  guards  ON  sensitivity  lists ;  1 

{ statements }  j 

end  process;  j 

FUNCTION_ROM;  process  | 

begin  j 

WAIT  UNTIL  guard4  ON  sensitivity  list4;  j 

{statements}  j 

end  process;  I 

end  BEHAVIOR;  1 

I 

\ . / 

Figure  4-9.  Architecture  With  Process  Statements  Converted 


port  slices)  were  used  in  the  process.  By  using  only  these 
to  form  the  ports  of  the  new  entity,  creation  of  unused 
ports  was  avoided.  The  port  and  alias  declarations  of  the 
original  entity  and  architecture  were  used  to  form  the  port 
declarations  for  the  new  entity.  The  mode  was  also  main¬ 
tained  from  the  original  entity  for  each  port  declaration  in 
each  new  entity.  An  exception  was  the  IDAS  requirement  to 
convert  mode  BUFFER  to  mode  INOUT  for  one  of  the  ports. 
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Another  consideration  was  the  use  of  generics.  If  a 
variable  which  matched  a  generic  was  found  in  a  process 
statement,  a  generic  clause  was  created  for  the  new  entity 
representing  the  process.  In  the  FPASP  implementation,  only 
one  process  used  the  generics  defined  by  the  original  enti¬ 
ty,  so  only  the  entity  for  that  process  contained  a  generic 
clause . 

After  all  entities  representing  the  process  statements 
in  the  design  were  created,  it  was  time  to  create  the  new 
subarchitectures .  This  is  an  easy  step  at  this  point  in  the 
translation  process.  The  first  action  required  to  construct 
each  new  architecture  was  to  create  the  architecture  header. 
The  architecture  header  consisted  of  the  keyword  "architec¬ 
ture",  followed  by  the  architecture  name  (BEHAVIOR),  fol¬ 
lowed  by  the  keyword  "of",  followed  by  the  entity  name, 
followed  by  the  keyword  "is".  The  body  of  the  architecture 
was  simply  the  keyword  "begin"  followed  by  the  process 
statement  followed  by  the  phrase  "end  BEHAVIOR;".  A  repre¬ 
sentation  of  the  new  architecture  is  provided  in  Figure  4- 
10. 

Now  that  each  process  statement  was  converted  into  an 
entity  and  architecture  pair,  the  final  step  of  architecture 
conversion  was  to  create  the  new  FPASP4_UDATAPATH  architec¬ 
ture.  Each  new  entity  was  represented  by  a  component  with 
the  same  name  as  the  entity  and  with  the  same  port  declara¬ 
tions  as  the  entity  --  as  required  for  JRS  styled  VHDL. 
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\ 

I 

Architecture  BEHAVIOR  of  UPPER_REGISTERS  is  I 

I 

begin  | 

I 

UPPER_REGISTERS :  process  | 

begin  j 

WAIT  UNTIL  guardl  ON  sensitivity  listl;  1 

{statements}  1 

end  process;  I 

I 

end  BEHAVIOR;  I 

I 

\ - - - - - / 

Figure  4-10.  Representation  of  New  Architecture 

Each  component  was  then  instantiated  and  the  ports  assigned 
to  the  port  or  port  slice  of  the  original  FPASP4_UDATAPATH 
entity.  Finally,  the  statements  which  were  outside  any 
process  statement  of  the  original  architecture  were  included 
in  a  begin-end  block.  Figure  4-11  provides  an  outline 
representation  of  the  results  of  this  process.  Conversion 
of  the  FPASP4_UDATAPATH  architecture  was  now  complete . 

4.2.4  Procedure  Mapping .  As  explained  in  Section 
3.4.4  the  task  of  mapping  one  procedure  to  another  is  quite 
difficult.  One  way  would  be  to  use  exhaustive  testing,  but 
two  problems  hinder  using  this  solution  for  Style-V.  The 
test  driver  for  testing  the  procedures  and  comparing  the 
resuj.ts  does  not  exist  and  would  require  a  major  development 
effort  to  produce.  Secondly,  given  the  facts  described  in 
Section  3; 4. 4,  even  simple  procedures  could  not  be  "fully" 
tested  in  an  acceptable  amount  of  time. 
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1  Architecture  BEHAVIOR  of  FPASP4_UDATAPATH  is  1 

I  I 

I  component  UPPER_REGISTERS  declaration  I 

I  I 

I  component  ALU_ShiFTER  declaration  1 

1  I 

I  component  LITERAL_INSERTER  declaration  | 

I  I 

I  component  FUNCTION_ROM  declaration  | 

I  I 

I  begin  | 

I  i 

I  component  UPPER_REGISTERS  instantiation  | 

I  1 

I  component  ALU_SHIFTER  instantiation  | 

I  I 

I  component  LITERAL_INSERTER  instantiation  | 

I  I 

I  component  FUNCTION_ROM  instantiation  | 

I  I 

I  statements  not  included  in  any  process  I 

I  I 

I  end  BEHAVIOR;  | 

I  I 

\ . / 

Figure  4-11.  New  Architecture  After  Conversion 

The  process  chosen  for  Style-V  was  manual  intervention, 
since  no  automated  method  seems  possible  at  this  time.  The 

remainder  of  this  section  describes  how  a  sampling  of  FPASP 

functions  were  mapped  to  JRS  IDAS  functions  and  describes  a 

case  where  a  mapping  was  not  possible. 

The  FPASP  procedure  MOVNUL  had  one  input  bus  type  and 
one  output  bus  type .  This  procedure  mapped  easily  to  the 
IDAS  MOVE  procedure  which  could  support  these  ports  while 
providing  the  same  functionality.  This  same  process  was 
used  on  six  other  functions  with  good  success.  Figure  4-12 
provides  the  FPASP  procedure  declarations  and  the 
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declarations  for  the  IDAS  procedure  to  which  they  mapped  for 
three  of  the  successful  mappings.  However,  one  PPASP  proce¬ 
dure  could  not  be  mapped  to  an  IDAS  procedure  or  combination 
of  IDAS  procedures . 

The  FPASP  procedure  SR  could  not  be  mapped  to  any  IDAS 
procedure.  The  declaration  of  this  "shift"  function  and  the 
"shift"  functions  provided  by  the  JRS  IDAS  are  provided  in 
Figure  4-13.  The  function  SR  accepts  a  word  (ALU_IN), 
assigns  the  rightmost  bit  to  an  out  bit  (SH_OUT),  shifts  the 
remaining  bits  one  bit  to  the  right,  and  assigns  an  input 
bit  (SH_IN)  to  the  leftmost  position  of  the  word  to  form  the 
result  (RESULT) .  None  of  the  IDAS  shift  procedures  provided 
this  capability. 

The  translation  method  of  transliteration  and  refine¬ 
ment  will  not  work  for  procedure  mapping  since  those  methods 
use  only  local  knowledge  to  perform  translations.  Addition¬ 
ally,  the  translation  method  of  abstraction  and  reimplemen¬ 
tation  will  probably  fail  to  be  capable  of  performing  the 
procedure  mappings,  since: 

the  key  to  the  increase  in  abstraction  ...  is  the 
ability  to  recognize  the  net  effects  of  a  computation. 
This  in  turn  depends  on  the  abstraction  component 
having  a  significant  amount  of  knowledge  about  what 
kinds  of  computations  can  be  performed.  (Waters, 
1986:14) 

The  information  provided  by  Waters  indicates  no  current 
technology  (transliteration  and  reimplementation 
orabstraction  and  reimplementation)  provides  a  solution  to 
the  problem  of  function  mapping  faced  by  Style_V. 
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FPASP 

MOVNUL  (MOV  IN 

in  DR32  RESOLVE  BUS  BIT  VECTOR(31  down to  0); 

RESULT 

out  DR32_RESOLVE  BUS_BIT_VECTOR( 31  downto  0)); 

IDAS 

MOVE  (In  Port  : 

iu  Data  Vector; 

Out  Port  : 

out  Data  Vector; 

Name  : 

"MOVNUL"  ); 

FPASP 

ORUL  (LEFT, RIGHT 

in  DR32  RESOLVE  BUS  BIT  VECTOR (31  downto  0); 

RESULT 

: 

out  DR32 

RESOLVE  BUS  BIT  VECTOR (31  downto  0); 

ZERO 

:  out  BUS_BIT  ); 

IDAS 

LOGICAL  OR  (In  Portl  :  in  Data  Vector; 

In  Port2  :  in  Data  Vector; 

Out  Port  :  out  Data  Vector; 

Status  :  out  Status  Type; 

Name 

:  "ORUL"  ) ; 

FPASP 

ADCUL  (LEFT, RIGHT  : 

in  DR32 

RESOLVE  BUS  BIT  VECTOR(31  downto  0); 

CARRY  IN 

:  in  BUS  BIT; 

RESULT 

out  DR32  RESOLVE  BUS  BIT  VECTOR(31  downto  0); 

CARRY 

:  out  BUS  BIT; 

OVERFLOW 

:  out  BUS  BIT; 

SIGN 

:  out  BUS  BIT; 

ZERO 

:  out  BUS_BIT; 

IDAS 

ADDC  (In  Portl 

in  Data  Vector; 

In  Port 2 

in  Data  Vector; 

In  Port3 

in  Data; 

Out  Port 

out  Data  Vector; 

Status 

out  Status  Type; 

Name 

"ADCUL"  ) ; 

\ 


\ 


Figure  4-12.  FPASP  to  IDAS  Procedure  Mapping  Examples 


/ 
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FPASP  SHIFT  RIGHT  PROCEDURE 


procedure  SR  (ALU_IN 

SH_IN 

RESULT 

SH  OUT 


;  in  DR32_RESOLVE 
BUS_BIT_VECTOR  (31  down to  0); 
;  in  BUS_BIT; 

;  out  DR32_RESOLVE 
BUS_BIT_VECTOR  (31  down to  0); 
:  BUS_BIT  ) ; 


JRS  IDAS  SHIFT  RIGHT  PROCEDURES 


procedure  SHIFT_RIGHT_1 

(In_Port 

Out_Port 

Name 


in  Data_Vector; 
out  Data_Vector; 
in  String  ) ; 


\- 


procedure  SHIFT_RIGHT_1_BIT_IN 

(In_Port  :  in  Data_Vector; 
In_Bit  :  in  Data; 

OutPort  :  out  Data_Vector; 
Name  :  in  String  ) ; 

procedure  SHIFT_RIGHT_1_0NEFILL 

(In_Port  :  in  Data_Vector; 
Out_Port  :  out  Data_Vector; 
Name  :  in  String  ) ; 


Figure  4-13.  FPASP  to  IDAS  NonMappable  Example 


•/ 


4.3  Lessons  Learned  From  Examples 

The  following  sections  provide  a  summary  of  the  lessons 
learned  during  the  manual  implementation  of  Style -V  trans¬ 
lations  on  the  FPASP  design.  The  difficulties  experienced 
during  these  implementations  and  the  lessons  learned  from 
them  indicate  care  should  be  used  when  developing  the  re¬ 
maining  modules  of  Style-V.  Lessons  are  also  good  for 
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insight  into  the  types  of  processes  necessary  for  developing 
a  successful  translator. 

4.3.1  Lessons  From  CASE  Conversion.  The  main  lesson 
learned  from  the  CASE  to  IF  analysis  and  implementation  was 
that  modifications  which  require  only  local  knowledge  in  the 
source  code  are  algorithmically  simple  to  design  and  imple¬ 
ment.  Little  temporary  storage  and  no  complicated  data 
structures  are  required  for  processing  translations  similar 
to  CASE  to  IF  conversion. 

4.3.2  Lessons  From  Type  Conversion.  The  main  lesson 
from  the  type  conversion  exercise  was  that  a  simple  approach 
is  sometimes  inappropriate,  and  it  may  be  plain  wrong.  A 
strong  analysis  should  always  be  conducted  to  determine  how 
a  course  of  action  affects  the  entire  system.  In  the  case 
of  type  conversion,  it  would  have  been  wrong  to  simply 
compress  multilevel  logic  into  bit  logic  by  assigning  the 
values  '0'  or  '1'  to  some  other  previously  defined  value.  A 
thorough  analysis  showed  the  best  way  was  to  represent  each 
actual  bit  with  two  logical  bits. 

Another  translation  lesson  learned  from  type  conversion 
is  that  decisions  early  in  a  process  affect  design  decisions 
throughout  the  translation.  For  instance,  the  decision  to 
represent  an  actual  multilevel  logic  bit  by  two  bits  of  bit 
logic  required  modification  of  the  functions  and  procedures 
which  operated  on  types.  Then,  the  modification  of  the  type 
functions  led  to  other  lessons. 
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One  of  the  lessons  was  that  range  bounds  and  loop 
ranges  all  needed  adjusting,  and  the  logic  of  loops  had  to 
be  changed  to  account  for  a  two-bit  representation  of  one 
actual  bit.  This  realization  confirms  that  type  conversion 
is  a  major  task  in  the  translation  effort.  All  functions 
and  procedures  of  a  design  must  be  tuned  to  handle  the 
changed  types,  otherwise  the  original  procedures  will  fail 
because  of  the  new  logical  representation  of  data. 

During  the  tuning  of  procedures,  other  conflicts  may 
occur.  For  overloaded  procedures  and  functions,  it  may 
happen  that  a  less  general  function  may  have  the  same  basic 
types  of  parameters  and  return  types  as  a  more  general 
function  with  the  same  name.  Since  this  is  not  allowed,  a 
data  structure  holding  the  previous  and  current  declarations 
of  functions  must  be  maintained.  In  this  manner,  any  con¬ 
flicting  less  general  function  may  be  renamed  and  retained 
for  use  by  the  more  general  function.  Calls  from  the  system 
to  the  function  would  now  go  to  the  more  general  function 
for  processing. 

Finally,  being  restricted  to  using  only  JRS  IDAS  pro¬ 
vided  functions  and  procedures  for  ALU-type  operations  meant 
a  translation  function  had  to  precede  and  follow  any  call  to 
IDAS  functions .  This  was  due  to  the  fact  that  the  IDAS 
functions  were  originally  written  to  process  datavectors 
which  are  two -level  logic  representations  of  data.  There¬ 
fore,  the  four-level  logic  representations  had  to  be 
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converted  to  two -level  logic  before  the  IDAS  procedure  and 
back  to  four-level  logic  after  the  IDAS  procedure.  Any 
logic  levels  other  than  '0'  or  '1'  would  be  lost  during  this 
process;  however,  that  was  not  expected  to  be  a  problem  as 
data  going  through  an  ALU-type  function  should  be  stable  at 
values  of  'O's  and  'I's. 

4.3.3  Lessons  From  Architecture  Conversion.  The  main 
lesson  of  the  architecture  conversion  exercise  was  to  under¬ 
stand  a  problem  before  looking  at  solution  alternatives . 
Sometimes  an  apparent  simple  solution  may  be  simply  wrong. 
For  the  architecture  conversion  problem,  the  simplest  and 
first  considered  option  was  to  combine  all  blocks  and  proc¬ 
esses  in  an  architecture  into  one  big  process  statement. 
However,  careful  analysis  showed  that  this  would  destroy  the 
parallelism  natural  with  the  multiple  processes  and  blocks. 
The  correct  solution  was  then  discovered  which  entailed 
creating  new  subarchitectures  for  each  process .  By  doing 
this,  the  parallelism  of  the  original  blocks  and  processes 
was  maintained. 

Another  lesson  was  that  using  multiple  passes  for 
certain  types  of  processing  problems  makes  the  task  easier 
to  complete.  In  the  case  of  architecture  conversion,  one 
pass  was  necessary  to  determine  the  declared  ports  and 
aliases  and  to  collect  the  statements  which  are  outside  any 
process  or  block  for  later  inclusion  in  the  final  architec¬ 
ture.  A  second  pass  is  used  to  create  a  sequence  of  process 
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statements  with  the  JRS  required  WAIT  statement.  A  third 
pass  creates  an  entity  for  each  of  the  process  statements . 

The  fourth  pass  creates  the  architecture  for  each  process . 
Finally,  a  fifth  pass  creates  the  new  architecture  which 
replaces  the  original  architecture. 

4.3.4  Lessons  From  Procedure  Mapping .  Procedure  mapping  is 
a  difficult  task.  It  requires  an  abstract,  logical  review  of  a 
subject  procedure  and  a  detailed  knowledge  of  the  procedures 
which  are  available  to  which  it  can  be  mapped.  Only  after 
reasoning  about  the  functions  performed,  can  one  hope  to 
successfully  map  the  procedures. 

Another  lesson  was  that  the  procedures  provided  by  IDAS  are 
a  proper  subset  of  the  functions  possible  for  a  VHDL  design  -- 
not  all  functions  are  included  in  the  subset.  This  causes  great 
problems  when  a  nonmappable  procedure  is  encountered  during 
a  manual  mapping  process  --an  indication  that  redesign  is 
required. 

4.4  Review 

This  chapter  has  provided  a  demonstration  of  some  of 
the  concepts  of  translating  standard  VHDL  into  the  JRS  IDAS 
subset  of  VHDL.  The  manual  implementations  of  CASE  state¬ 
ment  conversion,  type  conversion,  architecture  conversion, 
and  procedure  mapping  were  accomplished  to  demonstrate  the 
feasibility  of  building  Style-V  to  translate  standard  VHDL 
to  the  JRS  subset.  The  lessons  learned  from  these  manual 
implementations  were  also  discussed.  The  important  points 
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which  this  chapter  points  out  are  that  some  translations 
like  CASE  statement  and  architecture  conversion  are  easy, 
some  like  type  conversion  are  difficult,  and  yet  others  like 
procedure  mapping  are  presently  impossible  for  an  automated 
system. 
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V.  Results.  Conclusions. 
and  Recommendations 

5.0  Introduction 

Chapter  1  of  this  thesis  identified  the  need  to  trans¬ 
late  VHDL  written  in  the  IEEE  standard  language  to  a  subset 
of  the  VHDL  language  defined  for  a  microcode  generating 
tool.  After  stating  the  problem,  Chapter  1  described  the 
goals  of  the  research  effort  --  to  design  a  translator  to 
fulfill  the  need.  Another  key  section  of  Chapter  1  was  the 
section  discussing  the  assumptions  about  the  translator, 
research,  and  IDAS  tool. 

Unfortunately,  one  of  the  key  assumptions  stated  in 
Chapter  1  proved  to  be  incorrect.  The  assumption  was  made 
that  the  IDAS  tool  would  accept  stylized  VHDL  and  an  Ada 
program  and  produce  microcode  for  the  VHDL  design.  However, 
despite  the  efforts  of  local  experts,  including  some  calls 
to  the  IDAS  maker,  JRS  Research  Laboratories,  the  IDAS  would 
not  process  the  files  created  to  test  the  concept  of  gener¬ 
ating  microcode.  This  meant  that  any  translation  could  not 
be  tested  against  the  IDAS  tool.  When  this  situation  became 
apparent,  the  focus  of  the  research  effort  turned  to  per¬ 
forming  manual  simulations  to  demonstrate  the  feasibility  of 
the  concepts  required  for  a  successful  translation. 
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Chapter  2  consisted  of  a  literature  review  to  determine 
the  current  technologies  for  translating  computer  languages. 
The  essential  activities  of  lexical  analysis  and  parsing 
were  researched  since  any  translator  would  need  to  perform 
these  functions.  Also,  several  examples  of  translators  were 
reviewed. 

Chapter  3  was  a  requirements  analysis  of  the  translator 
system  (called  Style-V) .  This  analysis  consisted  of  a 
domain  analysis,  language  comparison,  and  Modern  Structured 
Analysis.  Domain  analysis  determined  what  composed  a  trans¬ 
lator  system.  Once  the  components  of  the  translator  were 
identified,  the  analysis  turned  to  the  specific  problem  of 
translating  the  standard  VHDL  into  a  subset. 

A  careful  comparison  of  the  standard  VHDL  to  tlie  styled 
VHDL  form  was  conducted.  The  results  of  the  domain  ’analysis 
and  the  VHDL  comparison  formed  the  basis  for  Modern  Struc¬ 
tured  Analysis. 

Modern  Structured  Analysis  was  used  to  determine  the 
processes  required  in  Style-V.  The  system  context,  external 
events,  and  event  behaviors  were  defined  and  analyzed  to 
determine  "how"  Style-V  would  perform  the  translation  task. 
Enough  detail  was  achieved  to  successfully  perform  desktop 
simulations  of  Style-V  processes. 

Chapter  4  documented  the  performance  of  the  desktop 
simulations  to  demonstrate  the  feasibility  of  producing  the 
Style-V  translator.  Not  all  processes  were  demonstrated. 
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but  a  representative  subset  of  the  processes  provided  enough 
information  to  determine  if  a  Style-V  translator  could  be 
fully  automated.  Chapter  4  also  included  the  lessons 
learned  from  the  manual  implementations . 

This  chapter  provides  a  summary  of  the  results  of  this 
thesis  effort,  some  conclusions  based  on  the  results,  and 
recommendations  based  on  the  conclusions.  The  original  goal 
of  fully  developing  the  Style-V  translator  was  not  realistic 
and  the  scope  of  the  thesis  was  adjusted.  In  the  final 
analysis,  the  problem  of  translating  standard  VHDL  into  the 
subset  required  by  JRS  for  the  IDAS  tool  was  too  large  to 
complete  in  one  thesis  cycle.  This  thesis  has  produced  an 
analysis  of  the  problem  and  demonstrated  how  some  transla¬ 
tion  tasks  can  be  automated  and  why  others  cannot. 

5.1  Results 

Once  the  decision  was  made  to  design  Style-V,  one  of 
the  first  efforts  was  to  construct  a  simple  example  CPU  to 
verify  advertised  IDAS  capabilities.  A  successful  demon¬ 
stration  of  the  IDAS  would  show  a  design  could  be  written  in 
the  stylized  form.  It  would  also  show  the  assumption  that 
the  IDAS  would  work  «vas  correct.  However,  the  result  of 
this  effort  showed  the  assumption  was  incorrect.  Another 
result  was  the  VHDL  code  for  the  sample  system.  The  VHDL 
code  for  this  system  is  included  in  Appendix  A. 
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The  next  results  of  this  research  were  those  obtained 
from  the  analysis  process.  The  domain  analysis  of  the 
system  provided  an  understanding  of  the  parts  composing  any 
translator  system.  The  decomposition  of  the  translator 
system  into  its  constituent  parts  is  documented  in  Figures 
3-1  through  3  -  5 . 

The  comparison  of  IEEE  standard  VHDL  to  the  stylized 
form  required  by  the  IDAS  tool  resulted  in  a  set  of  mappings 
for  the  Style-V  translator  to  satisfy.  These  mappings  are 
identified  in  Figure  3-6.  It  was  during  the  evaluation  of 
these  mappings  that  it  became  apparent  that  more  than  one 
thesis  cycle  would  be  required  to  complete  a  Style-V  design 
and  implementation. 

After  identifying  the  mappings  required  between  stand¬ 
ard  and  stylized  VHDL,  the  Modern  Structured  Analysis  of  the 
system  resulted  in  a  description  of  Style-V  in  sufficient 
detail  to  complete  the  manual  simulations.  The  products  of 
the  analysis  consisted  of  the  level  one  and  level  two  data 
flow  diagrams  and  a  data  dictionary  for  processes  necessary 
to  translate  all  defined  mappings.  The  data  flow  diagrams 
and  data  dictionary  are  included  Chapter  3 . 

During  completion  of  the  Chapter  3  processes,  the 
amount  of  time  required  to  simulate  all  mappings  was  deemed 
to  be  greater  than  the  amount  available.  At  that  point,  the 
mappings  CASE_to_IF,  Type  Conversion,  Architecture 
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Conversion,  and  Procedure  Mapping  were  selected  for  manual 
implementation . 

The  manual  implementation  of  CASE  statement  conversion 
resulted  in  a  successful  algorithm  for  converting  CASE 
statements  to  IF-THEN-ELSIF-ELSE  statements  or  IF-THEN 
statements.  The  CASE  statement  to  IF  statement  mapping  was 
the  only  mapping  chosen  for  full  implementation.  The  proto¬ 
type  CASE_to_IF  conversion  module  is  included  in  Appendix  D 
of  this  thesis.  However,  since  the  IDAS  did  not  perform  as 
expected,  it  was  not  possible  to  test  if  the  output  of  the 
module  was  acceptable  or  if  further  adjustments  were  re¬ 
quired. 

Architecture  conversion  was  more  challenging  than  CASE 
statement  conversion.  Like  the  CASE  statement  conversion, 
only  one  input  file  is  manipulated  at  any  one  time.  Howev¬ 
er,  several  passes  are  required  over  this  file  to  produce 
subarchitectures.  The  results  of  the  architecture  conver¬ 
sion  manual  implementation  were  an  algorithm  to  accomplish 
it,  a  new  architecture  at  the  same  level  in  the  system  as 
the  original  architecture,  and  four  architectures  one  level 
beneath  the  new  architecture.  The  algorithm  was  provided  in 
Chapter  4  and  the  resulting  architectures  are  in  Appendix  C . 

Type  conversion  proved  to  be  quite  a  challenge,  even 
for  a  manual  implementation.  One  of  the  results  of  the 
effort  was  the  use  of  bit  logic  to  represent  multilevel 
logic.  Another  result  was  a  translated  type  definition 
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package  for  the  Floating  Point  Application  Specific  Proces¬ 
sor.  The  results  of  the  translation  of  all  the  declarations 
and  over  fifty  functions  and  procedures  in  this  type  defini¬ 
tion  package  processed  successfully  through  VHDL  analysis. 

The  final  task  completed  for  the  demonstration  of 
concept  effort  was  to  attempt  mapping  procedures  from  the 
Floating  Point  Application  Specific  Processor  (FPASP)  to  the 
IDAS.  Eight  of  the  FPASP  processes  were  selected  for  map¬ 
ping  and  seven  mapped  successfully.  However,  no  mapping  of 
IDAS  procedures  was  found  to  satisfy  the  requirements  of  one 
FPASP  procedure  --  SR  which  shifted  a  bit  out  the  right  side 
of  a  word  and  a  bit  in  the  left  side.  The  potential  for 
this  problem  was  identified  in  Sections  3.4.4  and  3, 5. 3. 6, 
and  the  manual  implementation  confirmed  the  analysis.  The 
manual  implementation  results  are  documented  in  Sections 
4.2.4  and  4.3.4. 

5.2  Conclusions  and  Recommendations 

Regardless  of  the  IDAS  shortcomings,  the  design  of  the 
simple  CPU  was  successful.  The  design  simulates  well 
through  a  VHDL  system  and  may  be  useful  in  a  course  on  VHDL 
or  as  an  example  system  for  future  research.  Since  the  VHDL 
code  for  the  simple  CPU  runs  in  a  VHDL  system,  a  future 
researcher  need  not  repeat  this  work,  saving  many  hours  of 
development  effort. 

When  the  IDAS  failed  to  accept  the  simple  CPU,  a  limi¬ 
tation  of  the  tool  was  manifested.  This  revelation  alerted 
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the  holders  of  the  tool  that  portions  of  it  need  further 
attention.  They  can  now  work  with  the  vendor  to  have  the 
tool  completed.  Unfortunately,  this  was  not  possible  during 
this  thesis  effort. 

The  results  of  domain  analysis  provided  a  good  founda¬ 
tion  for  understanding  the  parts  of  a  translator  system  and 
how  they  interact.  The  techniques  described  in  this  thesis 
can  be  used  to  perform  a  domain  analysis  on  other  systems. 
Specifically,  anyone  beginning  a  research  effort  on  transla¬ 
tion  systems  need  not  repeat  this  work. 

Modern  Structured  Analysis  provided  an  appropriate 
means  for  defining  the  Style -V  translator.  This  research 
adopted  the  view  that  translating  languages  is  a  functional 
problem;  therefore,  a  functional  approach  to  the  analysis 
and  design  of  the  system  was  appropriate.  The  data  flow 
diagrams  and  data  dictionary  techniques  used  for  defining 
Style -V  provide  a  good  level  of  detail  to  facilitate  further 
design.  The  techniques  used  for  Style-V  are  equally  ap¬ 
plicable  to  like  tasks.  Future  research  efforts  should 
consider  using  these  same  techniques. 

CASE  statement  to  IF  statement  conversion  proved  to  be 
relatively  simple  to  accomplish.  Since  only  local  knowledge 
was  required  to  perform  the  translation  (from  the  CASE 
keyword  to  the  END  CASE  phrase),  complex  data  structures  and 
file  manipulation  was  not  required.  In  fact,  only  a  single 
pass  over  a  file  was  required  to  perform  CASE  statement  to 
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IF  statement  conversion.  The  methods  used  during  the  manual 
and  actual  implementations  of  CASE  statement  conversion 
would  be  appropriate  for  other  "single-pass"  type  problems. 

For  architecture  conversion,  use  of  data  structures  is 
required  to  successfully  perform  architecture  conversion. 

For  this  effort,  linked  lists  would  suffice  since  a  small 
number  of  elements  would  be  in  any  one  list.  Adding  items 
to  the  linked  list  requires  order  one  time.  Since  all  items 
in  a  list  are  usually  used  at  the  same  time,  it  would  take 
order  n  time  to  retrieve  all  n  items .  Researchers  should 
study  their  problems  and  select  the  best  data  structures  for 
solving  them. 

Once  the  use  of  bit  logic  for  multilevel  logic  was 
determined,  conversion  of  declarations  and  constants  was 
relatively  simple  --  it  was  basically  a  textual  substitution 
process.  However,  the  conversion  of  functions  (including 
procedures)  was  quite  a  different  matter.  The  logic  of 
internal  loops  had  to  be  changed  to  properly  manipulate  the 
multiple  bit  representations  of  single  logical  bits.  There¬ 
fore,  loop  indexes,  assignment  statement  logic,  and  addition 
of  "skip_this_time"  logic  was  necessary.  Also,  type  con¬ 
flicts  on  previously  compatible  overloaded  functions  were 
possible.  These  problems  were  difficult  to  solve  by  hand 
and  a  full  implementation  of  type  conversion  will  require  a 
great  deal  of  further  analysis  and  design.  This  task  alone 
might  warrant  a  future  thesis  effort. 
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The  most  difficult  task  of  the  Style-V  was  the  mapping 
of  user  defined  procedures  into  IDAS  provided  procedures. 

For  cases  when  the  functionality  of  each  procedure  is  known 
and  a  combination  of  IDAS  procedures  (possibly  one)  can 
perform  the  user  defined  procedure's  functionality,  the 
mapping  is  possible.  However,  since  the  IDAS  procedures  are 
limited,  it  is  not  possible  to  map  all  possible  procedures 
to  the  IDAS  procedures .  This  thesis  provided  one  example  of 
a  procedure  which  could  not  map  to  IDAS  procedures . 

In  general,  the  automated  mapping  of  procedures  is  a 
"hard"  task.  This  thesis  has  shown  that  exhaustive  testing 
is  not  a  realistic  answer  to  proving  two  procedures  are 
functionally  equivalent.  With  some  risk,  equivalence  class¬ 
es  could  reduce  the  number  of  tests  required  to  ascertain  if 
two  procedures  are  functionally  "equal"  to  one  another. 
However,  a  program  which  would  take  two  procedures  with 
unrestricted  numbers  and  types  of  parameters  as  input,  which 
would  produce  meaningful  test  data,  and  which  would  deter¬ 
mine  if  the  procedures  are  equal  is  also  a  "hard"  task. 

These  tasks  may  be  good  thesis  topics  for  those  in  the 
Artificial  Intelligence  specialty. 

5.3  Epilogue 

The  restrictions  of  the  IDAS  were  numerous .  Other 
tools  may  force  less  serious  restrictions.  For  those  tools, 
the  methods  described  in  this  thesis  may  prove  sufficient. 
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Appendix  A.  Haves  CPU  VHDL  Design 

This  appendix  contains  the  VHDL  code  representing  the 
design  of  the  simple  CPU  described  by  Hayes  (Hayes, 
1988:315).  The  design  represented  a  simple  model  coded  in 
the  style  of  VHDL  required  by  the  JRS  IDAS  tool.  Besides 
showing  the  potential  for  using  JRS  styled  VHDL  to  create  a 
design,  this  code  may  be  useful  for  a  course  on  VHDL. 

Future  research  efforts  on  VHDL  translation  may  take  advan¬ 
tage  of  this  code  and  save  many  hours  of  development  effort. 


Code  Unit 

Paqe 

Accumulator 
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Address  Register 

A. 5 

Arithmetic  Logic  Unit 

A. 7 

Clock 
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Control  Unit 
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CPU 
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Data  Register 

A. 24 

Instruction  Register 
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Machine  Declarations 

A. 28 

Main  Memory 

A. 29 

Memory  Loader  Package 
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Test  Bench 

A. 35 
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--  HAYES'  CPU  --  MODELED  PROCEDDRALLY  IN  VHDL 


--  FILE:  AC.VHD  (ACCUMULATOR  COMPONENT) 


- -  AFFECTS : 

BY:  DR.VHD  (DATA  REGISTER  COMPONENT) 

ALU.VHD  (ARITHMETIC  LOGIC  UNIT  COMPONENT) 
CU.VHD  (CONTROL  SIGNALS) 

CLOCK. VHD  (CLOCK) 

ON:  ALU.VHD  (ARITHMETIC  LOGIC  UNIT  COMPONENT) 

DR.VHD  (DATA  REGISTER  COMPONENT) 

--  PURPOSE:  MODEL  OF  THE  ACCUMULATOR  OF  THE  SIMPLE  CPU 
DESCRIBED  BY  (HAYES  1988:315).  THIS  MODEL 
COMBINED  WITH  MODELS  OF  THE  OTHER  COMPONENTS  OP 
HAYES'  SIMPLE  CPU  WAS  USED  AS  A  TEST  CASE  FOR 
USING  THE  JRS  IDAS  TO  AUTOMATICALLY  GENERATE  MICRO¬ 
CODE  FOR  THE  DESIGNED  HARDWARE. 


--  AUTHOR:  CAPT  DENNIS  A.  RUMBLEY 
AFIT/ENG 

--  VERSION:  5 


--  DATE:  4  SEP  91  (Ver  4) 

14  OCT  91  (Ver  5)  Moved  delay  from  behavioral  IF  stmts 

and  eliminated  wire  delay. 


library  UTIL; 
use  UTIL. DATA_TYPES. all; 
use  UTIL. BEHAVIORS; 
use  UTIL. BEHAVIORS. all; 


entity  ACCUMULATOR  is 
generic  (  REG_DELAY 
BUS_DELAY 
WIRE_DELAY 
ALU_DELAY 
port(  DATA_PM_BUS 
DATA_PM_ALU 
DATA_TO_ALU 
DATA_TO_BUS 
C12 
C6 
C5 
C2 
Cl 
CO 


time  :-  5  ns  ; 
time  :-  1  ns  ; 
time  :-  1  ns  ; 
time  :-  7  ns  )  ; 
in  DATA_VECTOR(15  downto  0) 
in  DATA_VECTOR(15  downto  0) 
out  DATA_VECTOR(15  downto  0) 
out  DATA_VECTOR(15  downto  0) 
in  CONTROL  ; 
in  CONTROL  ; 
in  CONTROL  ; 
in  CONTROL  ; 
in  CONTROL  ; 
in  CONTROL  ; 
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CLK 


:  in  CLOCK  )  ; 


end  ACCUMULATOR; 


architecture  BEHAVIOR  of  ACCUMULATOR  is 
begin  --  architecture  ACCUMULATOR (BEHAVIOR) 
process 

variable  AC_CONTENTS  ;  data_vector(15  downto  0); 

begin 


wait  until  CLK  =  '1'; 

if  C6  -  '1'  then  wait  for  REG_DELAY  +  BUS_DELAy; 

end  if; 

if  (CO  -  '1'  or  Cl  -  '1'  or  C2  -  '1')  then 
behaviors . READ_REGISTER 

(reg  ->  ACCONTENTS  , 
out_port  ->  ACjCONTENTS  , 
neune  ->  "ACtoALU”  ) ; 

DATA_TO_ALU  <-  transport  AC_CONTENTS  after  REG_DELAY; 
--wait  for  REG_DELAY  +  WIRE_DELAY  +  BUS_DELAY  +  WIRE_DELAY 
+  ALU_DELAY  +  WIRE_DELAY  ; 
wait  for  ALU_DELAY  +  REG_DELAY  +  BUS_DELAY; 
behaviors .WRITE_REGISTER 

(in_port  ->  DATA_FM_ALU  , 
reg  ->  AC_CONTENTS  , 
name  ->  "ALUtoAC"  ); 

DATA_TO_ALU  <-  transport  AC_CONTENTS  after  REG_DELAY; 

end  if; 

if  C5  -  '1'  then 

behaviors . READ_REGISTER 

(reg  ->  AC_CONTENTS  , 
out_port  ->  ACjCONTENTS  , 
neune  ->  "ACtoDR"  ); 

DATA_TO_BUS  <-  transport  AC_CONTENTS  after  REG_DELAY; 

elsif  CLK  -  '1'  and  C5  -  '0'  then 

DATA_TO_BUS  <-  transport  b"0000000000000000" ; 

end  if; 

if  C6  -  '1'  then 

--wait  for  REGDELAY  +  WIRE_DELAY  +  BUS_DELAY  +  WIREDELAY; 
behaviors .WRITE_REGISTER 

(in_port  ->  DATA_FM_BUS  , 
reg  ->  AC_CONTENTS  , 
name  ->  '•ACfroraDR"  ); 

DATA_TO_ALU  <-  transport  AC_CONTENTS  after  REG_DELAY; 

end  if; 
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if  CLK 


-  '1'  and  C12  -  '1'  then 
behaviors . SHIPT_RIGHT_L0GICAL_1 

(in_port  ->  ACjCONTENTS  , 
outj)ort  ->  AC_CONTENTS  , 
name  ->  "RSHIFT_AC_PM_ALO"  ); 

DATA_TO_ALU  <-  transport  AC_CONTENTS  after  REG_DELAY 

end  if; 
end  process; 
end  BEHAVIOR; 
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--  HAYES'  CPU  --  MODELED  PROCEDURALLY  IN  VHDL 


--  FILE:  AR.VHD  (ADDRESS  REGISTER  COMPONENT) 

-  -  AFFECTS : 

BY:  DR.VHD  (DATA  REGISTER  COMPONENT) 

PC.VHD  (PROGRAM  COUNTER  COMPONENT) 

CU.VHD  (CONTROL  SIGNALS) 

CLOCK. VHD  (CLOCK) 

ON:  MEMORY. VHD  (MAIN  MEMORY  COMPONENT) 

--  PURPOSE:  MODEL  OF  THE  ADDRESS  REGISTER  OF  THE  SIMPLE  CPU 
DESCRIBED  BY  (HAYES  1988:315).  THIS  MODEL 
COMBINED  WITH  MODELS  OP  THE  OTHER  COMPONENTS  OF 
HAYES'  SIMPLE  CPU  WAS  USED  AS  A  TEST  CASE  FOR 
USING  THE  JRS  IDAS  TO  AUTOMATICALLY  GENERATE  MICRO¬ 
CODE  FOR  THE  DESIGNED  HARDWARE. 

--  AUTHOR:  CAPT  DENNIS  A.  RUMBLEY 
AFIT/ENG 

VERSION:  5 

--  DATE:  4  SEP  91  (Ver  4) 

15  Oct  91  (Ver  5)  Removed  wire  delay.  Moved  wait  out 
of  behavioral  IF  statements.  Incorporated  delay 
in  signal  assignment  statements .  Moved  CLK  test 
to  WAIT  statement  and  removed  it  from  the  IFs. 


library  UTIL; 
use  UTIL. DATA_TYPES. all; 
use  JTIL. BEHAVIORS; 
use  UTIL. BEHAVIORS. all; 


entity  ADDRESS_REGISTER  is 

generic  (  REG_DELAY  :  time  :-  5  ns; 

BUS_DELAY  :  time  :-  1  ns  ); 
port(  ADDR_FM_BUS  :  in  DATA_VECTOR ( 1 5  downto  0)  ; 

ADDR_TO_MEM  :  out  ADDRESS_VECTOR ( 1 5  downto  0)  ; 


CIO 

:  in 

CONTROL 

Cl 

;  in 

CONTROL 

C4 

:  in 

CONTROL 

C3 

:  in 

CONTROL 

CLK 

:  in 

CLOCK  ) 

end  ADDRESS  REGISTER; 
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architecture  BEHAVIOR  of  ADDRESS_REGISTER  xs 
begin  --  architecture  ADDRESS_REG( BEHAVIOR) 
process 

variable  AR_CONTENTS  :  address_vector ( 15  downto  0)  ; 

begin 

wait  until  CLK  -  '1'; 

wait  for  REG_DELAY  +  B0S_DELAY  ; 

if  C7  -  '1'  or  CIO  -  '1'  then 

behaviors .WRITE_REGISTER 

(in_port  ->  ADDR_FM_BUS  , 
reg  ->  AR_CONTENTS  , 
name  ->  "ADDR_FM_BOS"  ) ; 

AR_CONTENTS  :=  AR_CONTENTS  and  b"0001111111111111" ; 

end  if; 

ADDR_TO_MEM  <-  transport  AR_CONTENTS; 
end  process; 
end  BEHAVIOR; 
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--  HAYES'  CPU  --  MODELED  PROCEDURALLY  IN  VHDL 


--  FILE;  ALU.VHD  (ARITHMETIC  LOGIC  UNIT  COMPONENT) 

-  -  AFFECTS : 

BY:  AC.VHD  (ACCUMULATOR  COMPONENT) 

DR.VHD  (DATA  REGISTER  COMPONENT) 

CU.VHD  (CONTROL  SIGNALS) 

CLOCK. VHD  (CLOCK) 

ON:  AC.VHD  (ACCUMULATOR  COMPONENT) 

SR. VHD  (STATUS  REGISTER  COMPONENT) 

--  PURPOSE:  MODEL  OF  THE  ARITHMETIC  LOGIC  UNIT  OF  THE  SIMPLE 
CPU  DESCRIBED  BY  (HAYES  1988:315).  THIS  MODEL 
COMBINED  WITH  MODELS  OF  THE  OTHER  COMPONENTS  OP 
HAYES'  SIMPLE  CPU  WAS  USED  AS  A  TEST  CASE  FOR 
USING  THE  JRS  IDAS  TO  AUTOMATICALLY  GENERATE  MICRO¬ 
CODE  FOR  THE  DESIGNED  HARDWARE. 

--  AUTHOR:  CAPT  DENNIS  A.  RUMBLEY 

AFIT/ENG 

--  VERSION:  5 

--  DATE:  4  SEP  91  (Ver  4) 

15  OCT  91  (Ver  5)  Eliminated  wire  delay.  Moved  test 

for  CLK  -  '1'  to  WAIT  statement  from  IF. 
Moved  wait  from  behavioral  IF  statements. 


library  UTIL; 
use  UTIL. DATA_TYPES. all; 
use  UTIL. BEHAVIORS; 
use  UTIL. BEHAVIORS. all; 


entity  ARITHMETIC  LOGIC  UNIT  is 


generic  (  REG 

DELAY 

time 

:-  5  ns 

BUS 

DELAY 

time 

:  -  1  ns 

ALU 

DELAY 

time 

:  -  7  ns 

CLK 

PERIOD 

time 

:-  100 

port'  DATA_FM_AC 
DATA_FM_BUS 
DATA_TO_AC 
ZERO_STAT 
C2 
Cl 
CO 


ns  )  ; 

in  DATA_VECTOR(15  downto  0)  , 
in  DATA_VECTOR(15  downto  C;  , 
out  DATA_VECTOR ( 1 5  downto  0) 
out  STATUS  ; 
in  CONTROL  ; 
in  CONTROL  ; 
in  CONTROL  ; 
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CLK 


:  in  CLOCK  )  ; 


end  ARITHMETIC  LOGICJUNIT; 


architecture  BEHAVIOR  of  ARITHMETIC_LOGIC_UNIT  is 
begin  --  architecture  ARITHMETIC_LOGIC_UNIT (BEHAVIOR) 


process 

variable 

variable 

variable 

variable 

variable 

variable 

variable 

variable 

begin 


ADD16_RES0LT 
ADD16_STATUS 
AND16_RESDLT 
ANDl6_STATaS 
NOTl 6_RES0LT 
NOT16_STATUS 
IDLE_RESULT 
IDLE  STATUS 


data_vector(15 

status_type; 

data_vector(15 

status_type; 

data_vector(15 

status_type; 

dat a_vector (15 

status_type; 


downto  0 ) ; 
downto  0 ) ; 
downto  0 ) ; 
downto  0 ) ; 


wait  until  CLK  = 

wait  for  REG  DELAY  +  BUS  DELAY; 


if  CO  =  then 

--  "add"  behavior 
behaviors .ADD 

(in_portl  ->  DATA_FM_AC, 
in_port2  ->  DATA_FM_BUS, 
out_port  ->  ADD16_RESULT, 
status  ->  ADD16_STATDS, 
name  =>  "ADD16"  ); 

DATA_TO_AC  <=  transport  ADD16_RESULT  after  ALU_DELAY; 
if  ADD16_STATUS(zero)  =  one  then 

ZERO_STAT  <=  transport  '1'  after  ALU_DELAY; 

else 

ZERO_STAT  <-  transport  '0'  after  ALU_DELAY; 

end  if; 
end  if; 


If  Cl  =  '1'  then 
--  "and"  behavior 
behaviors . LOGICAL_AND 

(in_portl  “>  DATA_FM_AC, 
inport2  ->  DATA_FM_BUS, 
out_port  ->  AND16_RESULT, 
status  ->  AND16_STATUS, 
name  ->  "AND16"  ); 

DATA_TO_AC  <”  transport  AND16_RESULT  after  ALU_DELAY; 
if  AND16_STATUS(zero)  -  one  then 

ZERO_STAT  <-  transport  '1'  after  ALU_DELAY; 

else 

ZERO_STAT  <-  transport  '0'  after  ALU_DELAY; 
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end  if; 
end  if; 

if  C2  -  '1'  then 
--  "comp"  behavior 
behaviors .LOGICAL_NOT 

(in_port  “>  DATA_PM_AC, 

OUt_port  “>  NOTl 6_RESULT , 
status  ->  N0T16_STAT0S, 
name  *>  "NOTl 6"  ); 

DATA  TO  AC  <“  transport  N0T16_RES0LT  after  ALD_DELAY; 
if  N0T16_STATUS(zero)  »  one  then 

ZERO_STAT  <“  transport  '1'  after  ALU_DELAy; 

else 

ZERO  STAT  <“  transport  '0'  after  AL0_DELAy; 

end  if; 
end  if; 

if  not  (  CO  =  or  Cl  “  '1'  or  C2  -  '1'  )  then 
--  idle  state  "behavior" 
behaviors . MOVE 

(in_port  ■">  DATA_FM_AC/ 
out_port  ->  IDLE_RESOLT, 
status  —>  IDLE_STATOS/ 
name  ->  "ALa_IDLE"  ); 

DATA  TO  AC  <“  transport  IDLE_RESULT  after  ALU_DELAy; 
if  lDLB_STATUS(zero)  -  one  then 

ZER0_STAT  <-  transport  '1'  after  AL[J_DELAy; 

else 

ZER0_STAT  <-  transport  '0'  after  ALU_DELAy; 

end  if; 
end  if; 


end  process; 
end  BEHAVIOR; 
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--  HAYES'  CPU  --  MODELED  PROCEDURALLY  IN  VHDL 


--  FILE:  CLOCK. VHD  (CLOCK  COMPONENT) 

-  -  AFFECTS : 

BY:  none 

ON:  AC. VHD  (ACCUMULATOR  COMPONENT) 

ALU. VHD  (ARITHMETIC  LOGIC  UNIT  COMPONENT) 
AR.VHD  (ADDRESS  REGISTER  COMPONENT) 

CU.VHD  (CONTROL  UNIT  COMPONENT) 

DR. VHD  (DATA  REGISTER  COMPONENT) 

IR.VHD  (INSTRUCTION  REGISTER  COMPONENT) 

PC. VHD  (PROGRAM  COUNTER  COMPONENT) 

MEMORY. VHD  (MEMORY  COMPONENT) 

--  PURPOSE:  MODEL  OF  THE  SYSTEM  CLOCK  OF  THE  SIMPLE  CPU 
DESCRIBED  BY  (HAYES  1988:315).  THIS  MODEL 
COMBINED  WITH  MODELS  OP  THE  OTHER  COMPONENTS  OF 
HAYES'  SIMPLE  CPU  WAS  USED  AS  A  TEST  CASE  FOR 
USING  THE  JRS  IDAS  TO  AUTOMATICALLY  GENERATE  MICRO¬ 
CODE  FOR  THE  DESIGNED  HARDWARE. 

--  AUTHOR:  CAPT  DENNIS  A.  RUMBLEY 
AFIT/ENG 

--  DATE:  24  JULY  1991 


library  Util; 

use  Util. DATA_TYPES. all; 

use  Util .BEHAVIORS,  Util . BEHAVIORS . all; 

entity  sys_clock  is 
port 

(ck  :  in  clock; 

sysclk  :  out  clock); 
end  sys_clock; 

architecture  BEHAVIOR  of  SYS_CLOCK  is 
begin 
process 

VARIABLE  phaseO_out_pulse  :  clock; 

VARIABLE  reset_ck_out_pulse  :  clock; 

begin 

wait  on  ck; 
if  ck  ”  '1'  then 
BEHAVIORS. pulse 

( system_clock  ->  ck. 
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out_j)ulse  ->  phaseO_out_pulse, 

Naune  ->  "phaseO"); 

sysclk  <-  transport  phaseO_out_pulse  after  0  ns; 
end  if; 

if  ck  “=  '0'  then 
BEHAVIORS. pulse 

( system_clock  ->  ck, 
out_pulse  “>  reset_ck_out_j>ulse. 

Name  ->  "reset_ck"); 

sysclk  <“  transport  reset_ck_out_pulse  after  0  ns; 
end  if; 
end  process; 
end  BEHAVIOR; 
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--  HAYES'  CPD  --  MODELED  PROCEDORALLY  IN  VHDL 


--  PILE:  CO.VHD  (CONTROL  UNIT  COMPONENT) 

-  -  AFFECTS : 

BY:  IR.VHD  (INSTRUCTION  REGISTER  COMPONENT) 

SR.VHD  (STATUS  REGISTER  COMPONENT) 

CLOCK. VHD  (CLOCK) 

ON:  CU.VHD  (CONTROL  SIGNALS) 

--  PURPOSE:  MODEL  OF  THE  CONTROL  UNIT  OF  THE  SIMPLE  CPU 
DESCRIBED  BY  (HAYES  1988:315).  THIS  MODEL 
COMBINED  WITH  MODELS  OF  THE  OTHER  COMPONENTS  OF 
HAYES'  SIMPLE  CPU  WAS  USED  AS  A  TEST  CASE  FOR 
USING  THE  JRS  IDAS  TO  AUTOMATICALLY  GENERATE  MICRO¬ 
CODE  FOR  THE  DESIGNED  HARDWARE. 

--  AUTHOR:  CAPT  DENNIS  A.  RUMBLEY 
AFIT/ENG 

-  -  VERSION :  5 


--  DATE:  4  SEP  91  (Ver  4) 

15  Oct  91  (Ver  5)  Removed  redundant  CLK  test  from  IFs. 


library  UTIL; 

use  UTIL. DATA_TYPES. all; 

entity  CONTROL_UNIT  is 

generic  (  CU_DELAY  :  time  15  ns  )  ; 

port(  CU_INSTR 
ZSTATIN 
CONTROLS 
CLK 

end  CONTROL  UNIT  ; 


architecture  BEHAVIOR  of  CONTROL_UNIT  is 

begin  --  architecture  CONTROL_UNIT( BEHAVIOR) 

process 

begin 

wait  until  CLK  -  '0',v 


:  in  DATA_VECTOR(15  downto  0)  ; 

:  in  STATUS  ; 

:  out  CONTROL_VECTOR(12  downto  0)  ; 
:  in  CLOCK  )  ; 
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PROCESS  FETCH  CYCLE 


--  Process  AR  <-  PC 

CONTROLS  <-  transport  b"0010000000000"  after  CD_DELAy; 
wait  until  CLK' event  and  CLK  =  'O'; 

--  Process  READ  M 

CONTROLS  <-  transport  b" 0000000001000"  after  C0_DELAY; 
wait  until  CLK 'event  and  CLK  -  'O'; 

--  Process  PC  <-  PC  +  1  and  IR  <-  DR(OP) 

CONTROLS  <-  transport  b"0101000000000"  after  CU_DELAY; 
wait  until  CLK 'event  and  CLK  -  'O'; 


PROCESS  EXECUTE  CYCLE 


--  Process  LOAD  Instruction 
if  Ca_INSTR(15  downto  13)  »  b"000"  then 
--  Process  AR  <-  DR(ADR) 

CONTROLS  <-  transport  b"0000010000000 "  after  CD_DELAY; 
wait  until  CLK 'event  and  CLK  -  'O'; 

-  -  Process  READ  M 

CONTROLS  <-  transport  b"0000000001000"  after  Ca_DELAY; 
wait  until  CLK 'event  and  CLK  -  'O'; 

--  Process  AC  <-  DR 

CONTROLS  <-  transp-.rt  b"0000001000000"  after  C0_DELAY; 
end  if; 

--Process  STORE  Instruction 
if  ''U_INSTR(15  downto  13)  -  b"001"  then 
--  Process  AR  <-  DR (ADR) 

CONTROLS  <-  transport  b"0000010000000"  after  Ca_DELAY; 
wait  until  CLK'event  and  CLK  -  'O'; 

--  Process  DR  <-  AC 

CONTROLS  <-  transport  b"0000000100000"  after  CD_DELAY; 
wait  until  CLK'event  and  CLK  -  'O'; 

--  Process  WRITE  M 

CONTROLS  <-  transport  b"0000000010000"  after  CD_DELAY; 
end  if; 

--  Process  ADD  Instruction 
if  CU_INSTR(15  downto  13)  '  b"010"  then 
--  Process  AR  <-  DR (ADR) 

CONTROLS  <-  transport  b"0000010000000"  after  CU_DELAY; 
wait  until  CLK'event  and  CLK  -  'O'; 

--  Process  READ  M 

CONTROLS  <-  transport  b"0000000001000"  after  Ca_DELAY; 
wait  until  CLK'event  and  CLK  -  'O'; 

--  Process  AC  <-  AC  +  DR 

CONTROLS  <-  transport  b"0C00000000001"  after  CD_DELAY; 
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end  if; 


-  -  Process  AND  Instruction 

if  Ca_INSTR(15  downto  13)  -  b"011"  then 
--  Process  AR  <-  DR (ADR) 

CONTROLS  <-  transport  b" 0000010000000"  after  CU_DELAY; 
wait  until  CLK'event  and  CLK  -  'O'; 

-  -  Process  READ  M 

CONTROLS  <-  transport  b"0000000001000"  after  C0_DELAY; 
wait  until  CLK'event  and  CLK  -  'O'; 

--  Process  AC  <-  AC  /\  DR 
CONTROLS  <-  transport  b"0000000000010" ; 
end  if; 

--  Process  JUMP  Instruction 
if  CU_INSTR(15  downto  13)  -  b"100"  then 

CONTROLS  <-  transport  b"0000100000000"  after  CU_DELAY; 
end  if; 

--  Process  JUMPZ  Instruction 

if  CU_INSTR(15  downto  13)  -  b"101"  and  ZSTAT_IN  -  '1'  then 
CONTROLS  <-  transport  b"0000100000000"  after  C0_DELAY; 
end  if; 

-  -  Process  COMP  Instruction 

if  ca_INSTR(15  downto  13)  -  b"110"  then 

CONTROLS  <“  transport  b"0000000000100"  after  Ca_DELAY; 
end  if; 

--  Process  RSHIFT  Instruction 
if  CU_INSTR(15  downto  13)  -  b"lll"  then 

CONTROLS  <=  transport  b"1000000000000"  after  CU_DELAY; 
end  if; 

end  process; 

end  BEHAVIOR; 
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--  HAYES'  SIMPLE  CPU  INSTANTIATED  ARCHITECTURE 


--  FILE:  CPU588_5.VHD  (588  CPU  INSTANTIATED  ARCHITECTURE) 

--  AFFECTS:  COMPLETE  HAYES'  SIMPLE  CPU  (ALL  COMPONENTS) 


--  PURPOSE:  PROVIDE  A  MECHANISM  TO  DEFINE  THE  SIGNALS  AND 

COMPONENTS  EXISTING  IN  THE  SIMPLE  CPU  DESIGN.  THIS 
ARCHITECTURE  WAS  USED  TO  DESCRIBE  THE  HAYES'  SIMPLE  CPU 
(HAYES  1988:315). 

--  AUTHOR:  CAPT  DENNIS  A.  RUMBLEY 
AFIT/ENG 


--  VERSION:  5 


--  DATE:  24  Sep  91 

revised  13  Oct  91  to  use  library  HAYES_CPU  instead 
of  library  PROC588. 

15  Oct  91  (Ver  5)  Created  a  new  higher  level  test  bench. 


library  UTIL; 
library  HAYES_VER5; 
use  UTIL. DATA_TYPES. all; 
use  UTIL. BEHAVIORS; 
use  UTIL. BEHAVIORS. all; 

use  HAYES_VER 5. MACHINE  DECLARATIONS . all ; 


entity  CPU588  is 

port  (  SYS_CLK  :  in  CLOCK  ); 
end  CPUS 88; 

architecture  BEHAVIOR  of  CPU588  is 


--  SIGNAL  DECLARATIONS 


signal  CTRL_BUS 
signal  ALUsigAC 
signal  ACsigALU 
signal  ACsigBUS 
signal  DRsigBUS 
signal  MEMsigBUS 
signal  PCsigBUS 
signal  BUSsig 
signal  ARsigMEM 
signal  IRsigCU 


CONTROL_VECTOR(12  downto  0)  ; 
DATA_VECTOR(15  downto  0)  ; 
DATA_VECTOR(15  downto  0)  ; 
DATA_VECTOR(15  downto  0)  ; 
DATA_VECTOR(15  downto  0)  ; 
DATA_VECTOR(15  downto  0)  ; 
ADDRESS_VECTOR(15  downto  0)  ; 
DATA_VECTOR(15  downto  0)  ; 
ADDRESS_VECTOR(15  downto  0)  ; 
ADDRESS_VECTOR(15  downto  0)  ; 
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signal  CLCXIKsig  :  CLOCK  ; 
signal  CLKpulseIN  :  CLOCK  ; 
signal  STATUSsig  :  STATUS  ; 


--  COMPONENT  DECLARATIONS 


component  ACCUMULATOR 

port  (DATA_FM_BUS  :  in  DATA_VECTOR( 15  downto  0)  ; 

DATA_FM_ALU  ;  in  DATA_VECTOR ( 1 5  downto  0)  ; 

DATA_TO_ALU  :  out  DATA_VECTOR ( 1 5  downto  0)  ; 
DATA_TO_BUS  :  out  DATA_VECTOR ( 15  downto  0)  ; 

Cl 2  ;  in  CONTROL  ; 

C6  :  in  CONTROL  ; 

C5  :  in  CONTROL  ; 

C2  :  in  CONTROL  ; 

Cl  :  in  CONTROL  ; 

CO  ;  in  CONTROL  ; 

CLK  :  in  CLOCK  ); 

end  component; 

for  all:  ACCUMULATOR  use  entity 

hayes_ver5 . ACCUMULATOR ( BEHAVIOR ) ; 

component  ARITHMETIC_LOGIC_UNIT 

port  (DATA_FM_AC  :  in  DATA_VECTOR( 15  downto  0)  ; 

DATA_FM_BUS  :  in  DATA_VECTOR ( 1 5  downto  0)  ; 

DATA_TO_AC  ;  out  DATA_VECTOR( 15  downto  0)  ; 
ZERO_STAT  :  out  STATUS  ; 

C2  :  in  CONTROL  ; 

Cl  :  in  CONTROL  ; 

CO  :  in  CONTROL  ; 

CLK  :  in  CLOCK  ) ; 

end  component; 

for  all:  ARITHMETIC_LOGIC_UNIT  use  entity 

hayes_ver 5 . ARITHMETIC_LOGIC_UNIT ( BEHAVIOR ) ; 


component  ADDRESS_REGISTER 

port  (ADDR_FM_BUS  :  in  DATAJVECTOR ( 1 5  downto  0)  ; 

ADDR_TO_MEM  :  out  ADDRESS_VECTOR ( 15  downto  0)  ; 

CIO  :  in  CONTROL  ; 

C7  :  in  CONTROL  ; 

C4  :  in  CONTROL  ; 

C3  :  in  CONTROL  ; 

CLK  :  in  CLOCK  )  ; 

end  component ; 

for  all:  ADDRESS_REGISTER  use  entity 

hayes_ver5 . ADDRESS_REGISTER ( BEHAVIOR ) ; 
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component  SyS_CLOCK 
port  (CK  :  in  CLOCK  ; 

SYSCLK  :  out  CLOCK  ) ; 
end  component; 

for  all:  SYS_CLOCK  use  entity  hayes_ver 5. SYS_CLOCK( BEHAVIOR ) ; 
component  CONTROL_UNIT 

port  (CU_INSTR  :  in  ADDRESS_VECTOR ( 15  downto  0)  ; 

ZSTAT_IN  :  in  STATUS  ; 

CONTROLS  :  out  CONTROL_VECTOR(12  downto  0)  ; 

CLK  :  in  CLOCK  ); 

end  component; 

for  all:  CONTROL_UNIT  use  entity 

hayes_ver5 . CONTROL_UNIT ( BEHAVIOR ) ; 


in  DATA_VECT0R(15  downto  0)  ; 
in  DATA_VECTOR(15  downto  0)  ; 
in  DATA_VECT0R(15  downto  0)  ; 
in  ADDRESS_VECT0R(15  downto  0)  ; 
out  DATA_VECT0R(15  downto  0)  ; 
out  DATA_VECTOR(15  downto  0)  ; 
out  DATA_VECT0R(15  downto  0)  ; 
out  DATA_VECT0R(15  downto  0)  ; 
out  DATA_VECT0R(15  downto  0)  ; 
out  DATA_VECTOR(15  downto  0)  ; 
out  DATA_VECTOR(15  downto  0)  ; 
in  CONTROL_VECTOR(12  downto  0)  ; 
in  CLOCK  )  ; 


component  DATABUS 
port  (DATA_FM_AC 
DATA_FM_DR 
DATA_FM_MEM 
ADDR_FM_PC 
DATA_TO_AC 
DATA_TO_ALU 
DATA_T0_AR 
DATA_TO_DR 
DATA_TO_IR 
DATA_TO_MEM 
DATA_TO_PC 
CONTROLS 
CLK 

end  component; 


for  all:  DATABUS  use  entity  hayes_ver5.DATABUS(BEHAVIOR) ; 
component  DATA_REGISTER 


port  {DATA_FM_BUS 
DATA_TO_BUS 
Cll 
C8 
C7 
C6 
C5 
C4 
C3 
Cl 
CO 
CLK 

end  component; 


in  DATA_VECTOR(15  downto  0)  ; 
out  DATA_yECTOR(15  downto  0) 
in  CONTROL 
in  CONTROL 
in  CONTROL 
in  CONTROL 
in  CONTROL 
in  CONTROL 
in  CONTROL 
in  CONTROL 
in  CONTROL 
in  CLOCK  ) ; 


for  all:  DATAREGISTER  use  entity 
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hayes_ver 5 . DATA_REGISTER ( BEHAVIOR ) ; 
component  INSTROCTION_REGISTER 

port  (DATA_FM_BDS  :  in  DATA_VECTOR ( 1 5  downto  0)  ; 

INST_TO_CU  :  out  ADDRESS_VECTOR(15  downto  0)  ; 

Cll  :  in  CONTROL  ; 

CLK  :  in  CLOCK  ); 

end  component; 

for  all:  INSTRaCTION_REGISTER  use  entity 

hayes_ver 5 . INSTRaCTION_REGISTER ( BEHAVIOR ) ; 

component  MAIN_MEMORY 

port  (DATA_FM_BUS  :  in  DATA_VECTOR( 15  downto  0)  ; 

DATA_TO_BUS  :  out  DATA_VECTOR { 1 5  downto  0)  ; 
ADDR_FM_AR  :  in  ADDRESS_VECTOR ( 15  downto  0)  ; 

C4  :  in  CONTROL  ; 

C3  :  in  CONTROL  ; 

CLK  :  in  CLOCK  ); 

end  component; 

for  all:  MAIN_MEMORY  use  entity 

hayes_ver5 . MAIN_MEMORY ( BEHAVIOR ) ; 

component  PROGRAM_COUNTER 

port  (DATA_FM_BUS  :  in  DATA_VECTOR ( 1 5  downto  0)  ; 

ADDR_TO_BUS  :  out  ADDRESS_VECTOR ( 15  downto  0)  ; 

CIO  :  in  CONTROL  ; 

C9  :  in  CONTROL  ; 

C8  :  in  CONTROL  ; 

CLK  :  in  CLOCK  ); 

end  component; 

for  all:  PROGRAM_COUNTER  use  entity 

hayes_ver5 . Pr  ^AM_CODNTER { BEHAVIOR ) ; 


begin  --  architecture  CPU588 (BEHAVIOR) 


--  COMPONENT  CONFIGURATIONS 


AC_588:  ACCUMULATOR 
port  map  ( 

DATA_FM_BUS  ->  BUSsig, 
DATA_FM_ALU  ->  ALUsigAC  , 
DATA_TO_ALU  ->  ACsigALU  , 
DATA_TO_BUS  ->  ACsigBUS  , 
Cl 2  ->  CTRL_BGS(12)  , 

C6  ->  CTRL_BUS(6)  , 
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C5  ->  CTRL_BDS(5)  , 

C2  ->  CTRL_BUS(2)  , 

Cl  “>  CTRL_B0S{1)  , 

CO  ->  CTRL_BUS(0)  , 

CLK  ->  CLOCKsig  ) ; 

ALU_588:  ARITHMETIC_LOGICJ[JNIT 
port  map  ( 

DATA_FM_AC  ->  ACsigALO  , 
DATA_PM_BUS  ->  BOSsig  , 
DATA_TO_AC  ->  ALOsigAC  , 
ZERO_STAT  ->  STATUSsig  , 

C2  ->  CTRL_BOS(2)  , 

Cl  ->  CTRL_BOS(l)  , 

CO  ->  CTRL_BUS(0)  , 

CLK  ->  CLOCKsig  ) ; 

AR_5 88:  ADORES S_R EG I S TER 
port  map  ( 

ADDR_FM_BUS  ->  BOSsig  , 
ADDR_TO_MEM  ->  ARsigMEM  , 
CIO  ->  CTRL_BUS(10)  , 

C7  ->  CTRL_BUS(7)  , 

C4  ~>  CTRL_BUS(4)  , 

C3  ->  CTRL_BOS(3)  , 

CLK  ->  CLOCKsig  ) ; 

CLK_588;  SYS_CLOCK 
port  map  ( 

CK  ->  CLKpulseIN  , 

SYSCLK  ->  CLOCKsig  ); 

CU_588:  CONTROL_UNIT 
port  map  ( 

CO_INSTR  ->  IRsigCU  , 
ZSTAT_IN  ->  STATUSsig  , 
CONTROLS  ->  CTRL_BOS  , 

CLK  ->  CLOCKsig  ); 

DB_588:  DA TABUS 
port  map  ( 

DATA_FM_AC  ->  ACsigBUS  , 
DATA_FM_DR  ->  DRsigBUS  , 
DATA_FM_MEM  ->  MEMsigBOS  , 
ADDR_FM_PC  ->  PCsigBUS  , 
DATA_TO_AC  ->  BOSsig  , 
DATA_TO_ALO  ->  BUSsig  , 
DATA_TO_AR  ->  BOSsig  , 
DATA_TO_DR  ->  BUSsig  , 
DATA_TO_IR  ->  BOSsig  , 
DATA_TO_MEM  ->  BOSsig  , 
DATA_TO_PC  ->  BOSsig  , 
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CONTROLS  ->  CTRL_BDS 
CLK  ->  CLOCKS ig  )  ; 


DR_588:  DATA_REGISTER 
port  map  ( 

DATA_FM_BOS  ->  BtJSsig  , 
DATA_TO_BUS  ->  DRsigBUS  , 
Cll  ->  CTRL_BOS(ll)  , 

C8  ->  CTRL_BDS(8)  , 

C7  ->  CTRL_BUS(7)  , 

C6  ->  CTRL_B0S(6)  , 

C5  ->  CTRL_BUS(5)  , 

C4  ->  CTRL_B0S(4)  , 

C3  ->  CTRL_B0S(3)  , 

Cl  ->  CTRL_BUS(1)  , 

CO  ->  CTRL_BDS{0)  , 

CLK  ->  CLOCKsig  ) ; 

IR_588;  INSTROCTION_REGISTER 
port  map  ( 

DATA_FM_BUS  ->  BUSsig  , 
INST_TO_CO  ->  IRsigCO  , 

Cll  ->  CTRL_BUS(11)  , 

CLK  ->  CLOCKsig  ) ; 

MEMORY_588:  MAIN_MEMORY 
port  map  ( 

DATA_FM_BUS  ->  BOSsig  , 
DATA_TO_BOS  ->  MEMsigBOS  , 
ADDR_FM_AR  ->  ARsigMEM  , 
C4  ->  CTRL__BaS(4)  , 

C3  ->  CTRL__BaS(3)  , 

CLK  ->  CLOCKsig  ) ; 

PC_588:  PROGRAM_CODNTER 
port  map  ( 

DATA_FM_BUS  ->  BUSsig  , 
ADDR_TO_BUS  ->  PCsigBDS  , 
CIO  ->  CTRL_BaS(10)  , 

C9  ->  CTRL_BUS(9)  , 

C8  ->  CTRL_BaS(8)  , 

CLK  ->  CLOCKsig  ); 


process 

begin 

wait  on  SYS_CLK; 

CLKpulseIN  <-  transport  SYS_CLK; 
end  process; 

end  BEHAVIOR; 
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--  HAYES'  CPU  --  MODELED  PROCEDURALLY  IN  VHDL 


--  FILE:  DB.VHD  (DATA  BUS  COMPONENT) 

-  -  AFFECTS : 

BY:  ail  components  (except  Control  Unit,  CU.VHD) 

ON:  all  components  (except  Control  Unit,  CU.VHD) 

--  PURPOSE:  MODEL  OF  THE  DATA  BUS  COMPONENT  OF  THE  SIMPLE  CPU 
DESCRIBED  BY  (HAYES  1988:315).  THIS  MODEL 
COMBINED  WITH  MODELS  OF  THE  OTHER  COMPONENTS  OP 
HAYES'  SIMPLE  CPU  WAS  USED  AS  A  TEST  CASE  FOR 
USING  THE  JRS  IDAS  TO  AUTOMATICALLY  GENERATE  MICRO¬ 
CODE  FOR  THE  DESIGNED  HARDWARE. 

--  AUTHOR:  CAPT  DENNIS  A.  RUMBLEY 

APIT/ENG 

--  VERSION;  5 

--  DATE:  4  SEP  91  (Ver  4) 

14  OCT  91  (Ver  5)  Moved  wait  out  of  behavioral  IF 

statements  and  put  signal  asgnmt 
delay  in  sig  asgnmt  statements. 


library  UTIL; 
use  UTIL. DATA_TYPES. all; 
use  UTIL. BEHAVIORS; 
use  UTIL. BEHAVIORS. all; 


entity  DATABUS  is 


generic  (  REG_DELAY  :  time  :-  5  ns; 

BUS_DELAY  :  time  1  ns; 

MEM  DELAY  :  time  10  ns  ); 

port(  DATA_FM_AC 

in  DATA_VECT0R(15  downto  0)  ; 

DATA_FM_DR 

in  DATA_VECT0R(15  downLo  0)  ; 

DATA_FM_MEM 

in  DATA_VECT0R(15  downto  0)  ; 

ADDR_FM_PC 

in  ADDRESS_VECT0R(15  downto  0) 

DATA_TO_AC 

out  DATA_VECT0R(15  downto  0) 

DATA_TO_ALU 

out  DATA_VECTOR(15  downto  0) 

DATA_TO_AR 

out  DATA_VECTOR(15  downto  0) 

DATA_TO_DR 

out  DATA_VECTOR(15  downto  0) 

DATA_TO_IR 

out  DATA_/ECTOR(15  downto  0) 

DATA_TO_MEM 

out  DATA_VECT0R(15  downto  0) 

DATA_TO_PC 

out  DATA_VECTOR(15  downto  0) 

CONTROLS 

in  CONTROL_VECTOR(12  downto  0) 

CLK 

in  CLOCK  )  ; 
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end  DATABUS; 


architecture  BEHAVIOR  of  DATABUS  is 
begin  --  architecture  DATABUS (BEHAVIOR) 
process 

variable  DB_CONTENTS  :  DATA_VECTOR ( 1 5  downto  0)  ; 

begin 

wait  until  CLK  =  '1'  ; 

if  CONTROLS(3)  ”  '1'  then  --ver5 

wait  for  MEM_DELAY; 
else  wait  for  REG_DELAY; 
end  if; 

if  CONTROLS  (0)  =■  '!•  or  CONTROLS(l)  =  '1'  or 

CONTROLS(4)  =  '1'  or  CONTROLS (6)  =  '1'  or 

C0NTR0LS(7)  =  '1'  or  CONTROLS(8)  -  '1'  or 

CONTROLS (11)  =  then 
behaviors .MOVE  ( 

in_port  =>  DATA_FM_DR  , 
out_port  “>  DB_CONTENTS  , 
name  ->  "DR  bus_to  ALU" 

)  ; 

end  if; 

if  CONTROLS(3)  >=  then 

behaviors .MOVE  ( 

in_port  “>  DATA_FM_MEM  , 
OUt_port  ->  DB_CONTENTS  , 
name  =>  "MEM  to  BUS" 

)  ; 

end  if; 

if  CONTROLS (5)  =  'V  then 
behaviors .MOVE  ( 

in_port  ->  DATA_FM_AC  , 
out_port  =>  DB_CONTENTS  , 
neune  ->  "AC  to  BUS" 

)  ; 

end  if ; 

if  CONTROLS (10)  -  '1'  then 
behaviors . MOVE  ( 

in_port  ->  ADDR_FM_PC  , 
out_port  ->  DB_CONTENTS  , 
name  »>  "PC  to  BUS" 

)  ; 

end  if; 
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DATA_TO_DR  <“  transport  DB_CONTENTS  after  BUS_DELAY; 
DATA_TO_AR  <=  transport  DB_CONTENTS  after  BUS_DELAY; 
DATA_TO_AC  <=  transport  DB_CONTENTS  after  BUS_DELAY; 
DATA_TO_IR  <=  transport  DB_CONTENTS  after  BUS_DELAY; 
DATA_TO_PC  <=  transport  DB_CONTENTS  after  BUS_DELAY; 
DATA_TO_ALU  <=  transport  DB_CONTENTS  after  BUS_DELAY; 
DATA_TO_MEM  <=  transport  DB_CONTENTS  after  BUS_DELAY; 


end  process; 
end  BEHAVIOR; 
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--  HAYES'  CPU  --  MODELED  PROCEDURALLY  IN  VHDL 


--  FILE;  DR.VHD  (DATA  REGISTER  COMPONENT) 

-  -  AFFECTS : 

BY:  AC.VHD  (ACCUMULATOR  COMPONENT) 

MEMORY. VHD  (MAIN  MEMORY  COMPONENT) 

CU.VHD  (CONTROL  SIGNALS) 

CLOCK. VHD  (CLOCK) 

ON:  MEMORY. VHD  (MAIN  MEMORY  COMPONENT) 

AR.VHD  (ADDRESS  REGISTER  COMPONENT) 

--  PURPOSE:  MODEL  OF  THE  DATA  REGISTER  OF  THE  SIMPLE  CPU 
DESCRIBED  BY  (HAYES  1988:315).  THIS  MODEL 
COMBINED  WITH  MODELS  OP  THE  OTHER  COMPONENTS  OF 
HAYES'  SIMPLE  CPU  WAS  USED  AS  A  TEST  CASE  FOR 
USING  THE  JRS  IDAS  TO  AUTOMATICALLY  GENERATE  MICRO¬ 
CODE  FOR  THE  DESIGNED  HARDWARE. 

--  AUTHOR:  CAPT  DENNIS  A.  RUMBLEY 

AFIT/ENG 

--  VERSION;  5 

--  DATE:  4  SEP  91  (Ver  4) 

15  OCT  91  (Ver  5)  Deleted  wire  delay.  Moved  wait  from 

behavioral  IFs.  Moved  test  for  CLK  °  '1' 
from  IFs  to  first  WAIT  statement. 


library  UTIL; 
use  UTIL. DATA_TYPES. all; 
use  UTIL. BEHAVIORS; 
use  UTIL. BEHAVIORS .all; 


entity  DATA_REGISTER  is 

generic  (  REG_DELAY  :  time  :-  5  ns; 

BUS_DELAY  ;  time  :”  1  ns; 

MEM_DELAY  :  time  :-  10  ns  )  ; 
port(  DATA_PM_BUS  :  in  DATA_VECTOR ( 1 5  downto  0)  ; 

DATA_TO_BUS  :  out  DATA_VECTOR ( 1 5  downto  0)  ; 
Cll  :  in  CONTROL  ; 

C8  :  in  CONTROL  ; 

C7  :  in  CONTROL  ; 

C6  :  in  CONTROL  ; 

C5  :  in  CONTROL  ; 

C4  :  in  CONTROL  ; 

C3  :  in  CONTROL  ; 
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Cl 

:  in 

CONTROL 

CO 

:  in 

CONTROL 

CLK 

:  in 

CLOCK  ) 

f 

end  DATA_REGISTER; 


architecture  BEHAVIOR  of  DATA_REGISTER  is 
begin  --  architecture  DATA_REGISTER( BEHAVIOR) 

process 

variable  DR_CONTENTS  :  DATA_VECTOR( 15  down to  0); 

begin 


wait  until  CLK  -  '1'; 

if  C3  -  '1'  then  wait  for  MEM_DELAY  +  B0S_DELAY; 
elsif  C5  -  '!•  then  wait  for  REG_DELAY  +  BUS_DELAY; 
end  if; 


if  {CO  -  or  Cl  -  '1'  or  C4  -  '1'  or 

C6  -  '1'  or  C7  -  '1'  or  C8  -  '1'  or  Cll  -  '1')  then 


behaviors . READ  REGISTER 


(  out_port  ->  DR_CONTENTS  , 
reg  ->  DR_CONTENTS  , 
name  ->  "DRtoBUS"  ); 

DATA_TO_BUS  <-  transport  DR_CONTENTS  after  REG_DELAY; 
elsif  CLK  -  '1'  and  not  (CO  =  '1'  or  Cl  -  '1'  or  C4  -  '1'  or 

C6  -  '1'  or  C7  -  '1'  or  C8  -  '1'  or  Cll  -  '1')  then 
DATA_TO_BUS  <-  transport  b"0000000000000000" 


end  if; 


after  REG  DELAY; 


if  C3  -  '1'  then 

behaviors .WRITE_REGISTER 

(reg  «>  DR_COMTENTS  , 
in_port  ->  DATA_FM_BUS  , 
rame  ->  "DRgetsMEM"  ); 

end  if; 


if  C5  -  '1'  then 

behaviors .WRITE_REGISTER 

(reg  ->  DR_CONTENTS  , 
in_port  ->  DATA_FM_BUS  , 
neune  ->  "DRgetsAC"  )  ; 

end  if; 


end  process; 
end  BEHAVIOR; 
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--  HAYES'  CPU  --  MODELED  PROCEDDRALLY  IN  VHDL 


--  FILE:  IR.VHD  (INSTRUCTION  REGISTER  COMPONENT) 

-  -  AFFECTS : 

BY:  DR.VHD  (DATA  REGISTER  COMPONENT) 

CU.VHD  (CONTROL  SIGNALS) 

CLOCK. VHD  (CLOCK) 

ON:  CU.VHD  (CONTROL  UNIT  COMPONENT) 

--  PURPOSE:  MODEL  OF  THE  INSTRUCTION  REGISTER  OF  THE  SIMPLE 
CPU  DESCRIBED  BY  (HAYES  1988:315).  THIS  MODEL 
COMBINED  WITH  MODELS  OF  THE  OTHER  COMPONENTS  OF 
HAYES'  SIMPLE  CPU  WAS  USED  AS  A  TEST  CASE  FOR 
USING  THE  JRS  IDAS  TO  AUTOMATICALLY  GENERATE  MICRO¬ 
CODE  FOR  THE  DESIGNED  HARDWARE. 

--  AUTHOR:  CAPT  DENNIS  A.  RUMBLEY 

AFIT/ENG 

--  VERSION:  5 

--  DATE:  4  SEP  91  (Ver  4) 

15  OCT  91  (Ver  5)  Moved  test  for  CLK  -  '1'  to  WAIT 

statement  from  IF  statement.  Eliminated 
wire  delay.  Moved  wait  out  of  behavioral 
IF  statement. 


library  UTIL; 
use  UTIL. DATA_TYPES .all; 
use  UTIL. BEHAVIORS; 
use  UTIL. BEHAVIORS. all; 


entity  INSTRUCTION_REGISTER  is 

generic  (  REG_DELAY  :  time  :•  5  ns; 

BUS_DELAY  :  time  :-  1  ns  ); 
port(  nATA_FM_BUS  :  in  DATA_VECTOR ( 1 5  downto  0)  ; 

INST_TO_CU  :  out  ADDRESS_VECTOR( 15  downto  0)  ; 
Cll  :  in  CONTROL  ; 

CLK  :  in  CLOCK  )  ; 

end  INSTRUCTION  REGISTER; 


architecture  BEHAVIOR  of  INSTRUCTION  REGISTER  is 
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begin  --  architecture  1NSTR0CTI0N_REGISTER( BEHAVIOR) 

process 

variable  IR_CONTENTS  :  DATA_VECTOR ( 1 5  downto  0); 

begin 

wait  until  CLK  -  '1'; 

wait  for  REG_DELAY  +  BUS_DELAY; 

if  Cll  -  '1'  then 

behaviors . WRITE_REGISTER 

(in_port  =>  DATA_FM_BUS  , 
reg  ->  IR_CONTENTS  , 
name  ->  "IRgetsDR"  ); 
behaviors . READ_REG1STER 

(reg  ->  IR_CONTENTS  , 
out_port  ->  IR_CONTENTS  , 
neime  ■•>  "COgetsIR"  ) ; 

INST_TO_CU  <=  transport  IR_CONTENTS  after  REG_DELAY 
else  INST_TO_CU  <=  transport  b"0000000000000000" ; 
end  if; 

end  process; 

end  BEHAVIOR; 
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MACHINE  DECLARATIONS  FOR  HAYES'  CPU 


--  FILE:  MACHDECL.VHD  (MACHINE  DECLARATION  PACKAGE) 

-  -  AFFECTS : 

BY :  none 

ON:  AC.VHD  (ACCUMULATOR  COMPONENT) 

ALU.VHD  (ARITHMETIC  LOGIC  UNIT  COMPONENT) 

AR.VHD  (ADDRESS  REGISTER  COMPONENT) 

DR.VHD  (DATA  REGISTER  COMPONENT) 

IR.VHD  (INSTRUCTION  REGISTER  COMPONENT) 

MEMORY. VHD  (MAIN  MEMORY  COMPONENT) 

PC.VHD  (PROGRAM  COUNTER  COMPONENT) 

--  PURPOSE:  SUPPLY  THE  MACHINE  DEPENDENT  TYPE  DECLARATIONS  AND 
ANY  RESOLUTION  FUNCTIONS  NEEDED  FOR  THE  SIMPLE  CPU 
DESCRIBED  BY  (HAYES  1988:315).  HAYES'  SIMPLE  CPU 
WAS  USED  AS  A  TEST  CASE  FOR  USING  THE  JRS  IDAS  TO 
AUTOMATICALLY  GENERATE  MICROCODE  FOR  THE  DESIGNED 
HARDWARE . 

--  AUTHOR:  CAPT  DENNIS  A.  RUMBLEY 
AFIT/ENG 

--  VERSION:  5 

--  DATE:  24  SEP  91  (Ver  4) 

15  OCT  91  (Ver  5)  Moved  memory  initialization  function  to  a 
separate  package  since  Package  Machine_Declara- 
tions  only  1)  defines  a  constant  cycle_length , 

2)  defines  machine  specific  bit_vectors,  and 

3)  defines  bus  subtypes  and  their  resolution 
functions. 


library  UTIL; 

use  UTIL. DATA_TYPES .all; 

package  MACHINE_DECLARATIONS  is 

constant  CLK_PERIOD  :  time  :=  100  ns; 

type  CONTROL_12_DOWNTO_0_VECTOR  is 

array ( integer  range  <>)  of  CONTROL_VECTOR(12  downto  0); 

end  MACHINE  DECLARATIONS; 
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--  HAYES'  CPU  --  MODELED  PROCEDORALLY  IN  VHDL 


--  FILE:  MEMORY5.VHD  (MAIN  MEMORY  COMPONENT) 


-  -  AFFECTS : 


BY :  DR . VHD 

AR . VHD 
CU . VHD 


(DATA  REGISTER  COMPONENT) 
(ADDRESS  REGISTER  COMPONENT) 
(CONTROL  SIGNALS) 


ON:  DR. VHD  (DATA  REGISTER  COMPONENT) 


--  PURPOSE:  MODEL  OF  THE  MEMORY  PORTION  OF  THE  SIMPLE  CPU 
DESCRIBED  BY  (HAYES  1988:315).  THIS  MODEL 
COMBINED  WITH  MODELS  OF  THE  OTHER  COMPONENTS  OF 
HAYES'  SIMPLE  CPU  WAS  USED  AS  A  TEST  CASE  FOR 
USING  THE  JRS  IDAS  TO  AUTOMATICALLY  GENERATE  MICRO¬ 
CODE  FOR  THE  DESIGNED  HARDWARE. 


--  AUTHOR:  CAPT  DENNIS  A.  RUMBLEY 
AFIT/ENG 

--  VERSION:  5 

DATE:  4  SEP  91  Version  i 

revised  24  SEP  91  to  use  ...brary  HAYES_CPU  instead 
of  library  PROC5u8. 

14  Oct  91  Version  5:  Moved  delay  from  behavioral  IF 
statements.  Eliminated  wire  delay, 
moved  test  for  CLK  =  '1'  to  WAIT  from  IF. 
Changed  working  library  from  HAYES_CPU  to 
HAYES  VERS . 


library  UTIL; 

use  UTIL. DATA_TYPES. all; 

use  UTIL. BEHAVIORS; 

use  UTIL. BEHAVIORS. all; 

use  UTIL. ATTRIBUTE_DECLARATIONS .all; 

library  HAYES_VER5; 

use  hayes_ver5 . MACHINE_DECLARATIONS ; 
use  hayes_ver5 . MACHINEDECLARATIONS . all ; 
use  hayes_ver5.MEMORY_LOADER; 
use  hayes_ver5 . MEMORY_LOADER . all ; 


entity  MAIN_MEMORY  is 


generic  (  REG_DELAY 
BUS  DELAY 
MEM_DELAY 
port(  DATA_FM_BUS 
DATA  TO  BUS 


:  time  :-  5  ns; 

:  time  :-  1  ns; 

:  time  :-  10  ns  ); 

in  DATA_VECTOR(15  downto  0) 
out  DATA_VECTOR( 15  downto  0 
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ADDR_PM_AR  :  in  ADDRESS_VECTOR( 15  downto  0)  ; 

C4  :  in  CONTROL  ; 

C3  ;  in  CONTROL  ; 

CLK  :  in  CLOCK  ); 

attribute  STARTING_ADDRESS  of  MAIN_MEMORY:  entity  is  0  ; 
attribute  ENDING_ADDRESS  of  MAIN_MEMORy:  entity  is  8192  ; 

end  MAIN_MEMORY; 


architecture  BEHAVIOR  of  MAIN_MEMORY  is 
begin  --  architecture  MAIN_MEMORY{ BEHAVIOR) 

process 

variable  TEMP_MEM  ;  data_15_downto_0_vector (8192  downto  0); 
variable  MEM_SPACE  :  data_15_downto_0_vector(8192  downto  0) 

: =  LOAD_MEMORY { TEMP_MEM) ; 

variable  MEM_CONTENTS  :  data_vector (15  downto  0)  ; 

begin 

wait  until  CLK  -  '1'; 

if  C4  -  then  wait  for  REG_DELAY  +  BDS_DELAY; 
end  if; 

if  C3  -  '1'  then 

behaviors . READ 

(memory  ->  MEM_SPACE  , 
address_port  ->  ADDR_FM_AR  , 
data_port  ->  MEM_CONTENTS  , 
name  =>  "READmem"  ) ; 

DATA_TO_BDS  <-  transport  MEM_CONTENTS  after  MEM_DELAy; 
elsif  C3  -  '0'  then 

DATA_TO_BUS  <-  transport  b"0000000000000000"  ; 

end  if; 

if  C4  -  then 

behaviors .WRITE 

(memory  ->  MEM_SPACE  , 
address_port  ->  ADDR_FM_AR  , 
data_port  ->  DATA_FM_BDS  , 
name  ->  "WRITEmem"  ) ; 

end  if; 
end  process; 


end  BEHAVIOR; 


MACHINE  DECLARATIONS  FOR  HAYES'  CPU 


--  FILE:  LOADMEM4.VHD  (MEMORY  LOADER  PACKAGE) 

-  -  AFFECTS : 

BY:  none 

ON:  MEMORY. VHD  (MAIN  MEMORY  COMPONENT) 

--  PURPOSE:  LOAD  THE  INITIAL  VALUES  FOR  THE  MEMORY  OF  THE  CPU 
DESCRIBED  BY  (HAYES  1988:315).  HAYES'  SIMPLE  CPU 
WAS  USED  AS  A  TEST  CASE  FOR  USING  THE  JRS  IDAS  TO 
AUTOMATICALLY  GENERATE  MICROCODE  FOR  THE  DESIGNED 
HARDWARE . 

--  AUTHOR:  CAPT  DENNIS  A.  RUMBLEY 
AFIT/ENG 

--  VERSION:  1  (SEPARATED  FROM  MACHDECL4 . VHD  TO  STYLIZE  THE 
MACHINE_DECLARATIONS  PACKAGE  FOR  IDAS  INPUT) 

--  DATE:  23  SEP  91 


library  UTIL; 

use  UTIL. DATA_TYPES. all; 

package  MEMORY_LOADER  is 

function  LOAD_MEMORY  (MEM_SPACE  :  in  DATA_1 5_DOWNTO_0_VECTOR ) 

return  data  15  downto  0  vector; 


end  MEMORY  LOADER; 


package  body  MEMORY_LOADER  is 


function  LOAD_MEMORY  (MEM_SPACE  :  in  DATA_1 5_DOWNTO_0_VECTOR ) 

return  data_15_downto_0_vector  is 
variable  M_SPACE  :  data_15_downto_0_vector(MEM_SPACE' range) 

:=  MEM_SPACE; 

begin 


--  Initialize  8K  Memory 
for  i  in  M_SPACE' range  loop 

M_SPACE(i)  :-  b"0000000000000000"; 
end  loop; 

--  LOAD  AC  with  contents  of  location  100  (-4) 
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M_SPACE(0)  b"0000000001100100 " ; 

M_SPACE{100)  b"0000000000000100" ; 

--  ADD  contents  of  location  101  (-2)  to  contents  of  AC  (=4) 
M_SPACE(1)  b"0100000001100101"; 

M_SPACE(101)  :=  b"0000000000000010" ; 

--  STORE  contents  of  AC  in  location  102  (should  be  =  6) 
M_SPACE(2)  :»  b"0010000001100110" ; 

--  AND  contents  of  AC  (-6)  with  contents  of  location  103  (-2) 
M_SPACE(3)  b" 0110000001100111" ; 

M_SPACE{103)  b"0000000000000010”  ; 

--  STORE  coiitents  of  AC  in  location  104 
M_SPACE(4)  b"0010000001101000" ; 

--  JUMP  to  location  10 

M_SPACE(5)  b"1000000000001010"  ; 

--  LOAD  AC  with  contents  of  location  7  (-0) 

M_SPACE(10)  b"0000000000000111" ; 

--  JUMPZ  to  location  15 
M_SPACE{11)  b"1010000000001111"; 

-  -  COMP  contents  of  AC 
M_SPACE(15)  b"1100000000000000" ; 

--  STORE  AC  in  location  105  (should  -  2**16) 

M_SPACE(16)  b"001000000110l001"  ; 

--  RSHIFT  contents  of  AC 
M_SPACE(17)  b"1110000000000000" ; 

--  STORE  AC  in  location  106  (should  -  2**15) 

M_SPACE(18)  b"0010000001101010"  ; 

return  M_SPACE; 

end  LOAD  MEMORY; 


end  MEMORY  LOADER; 
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--  HAYES'  CPU  --  MODELED  PROCEDURALLY  IN  VHDL 


--  FILE:  PC5.VHD  (PROGRAM  COUNTER  COMPONENT) 

-  -  AFFECTS : 

BY:  DR.VHD  (DATA  REGISTER  COMPONENT) 

CU.VHD  (CONTROL  SIGNALS) 

CLOCK . VHD  ( CLOCK ) 

ON:  AR.VHD  (ADDRESS  REGISTER  COMPONENT) 

--  PURPOSE:  MODEL  OF  THE  PROGRAM  COUNTER  OF  THE  SIMPLE  CPU 
DESCRIBED  BY  (HAYES  1988:315).  THIS  MODEL 
COMBINED  WITH  MODELS  OF  THE  OTHER  COMPONENTS  OF 
HAYES'  SIMPLE  CPU  WAS  USED  AS  A  TEST  CASE  FOR 
USING  THE  JRS  IDAS  TO  AUTOMATICALLY  GENERATE  MICRO¬ 
CODE  FOR  THE  DESIGNED  HARDWARE. 

--  AUTHOR:  CAPT  DENNIS  A.  RUMBLEY 

AFIT/ENG 

--  VERSION:  5 

--  DATE:  4  SEP  91  (Ver  4) 

15  OCT  91  (Ver  5)  Eliminated  wire  delay.  Moved  wait 
from  behavioral  IF  statements.  Moved  test 
for  CLK  -  '1'  to  WAIT  statement  from  IF. 


library  UTIL; 
use  UTIL. DATA_TYPES. all; 
use  UTIL. BEHAVIORS; 
use  UTIL. BEHAVIORS. all; 


entity  PROGRAM_COUNTER  is 

generic  (  REG_DELAY  :  time  5  ns; 

BUS_DELAY  :  time  :-  1  ns  ); 
port(  DATA_FM_BUS  :  in  DATA_VECTOR( 15  downto  0)  ; 

ADDR_TO_BUS  :  out  ADDRESS_VECTOR ( 15  downto  0)  ; 
CIO  :  in  CONTROL  ; 

C9  .  :  in  CONTROL  ; 

C8  :  in  CONTROL  ; 

CLK  :  in  CLOCK  )  ; 

end  PROGRAMCOUNTER ; 


architecture  BEHAVIOR  of  PROGRAM  COUNTER  is 
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begin  --  architecture  PRCX;RAM_COaNTER( BEHAVIOR) 

process 

variable  PC_CONTENTS  :  address_vector(15  downto  0); 

begin 

wait  until  CLK  -  '1'; 

if  C8  -  then  wait  for  REG_DELAY  +  BUS_DELAY; 

end  if ; 

if  C8  -  then 

behaviors . WRITE_REGISTER 

(in_port  =>  DATA_PM_BUS  , 
reg  ->  PCCONTENTS  , 
name  =>  "PCgetsDR"  ); 

end  if; 


if  C9  -  '1'  then 

behaviors . INC 

(in_port  =>  PC_CONTENTS  , 
out_port  =>  PC_CONTENTS  , 
name  ->  "incPC"  ); 

end  if; 


if  CIO 


else 


end  if; 


“  ' 1 '  then 

behaviors . READ_REGISTER 

(reg  ->  PC_CONTENTS  , 

OUt_port  ->  PC_CONTENTS  , 
name  ->  "PCtoAR"  ); 

ADDR_TO_BUS  <-  transport  PC_CONTENTS  after  REG_DELAY; 

ADDR_TO_BUS  <-  transport  b"0000000000000000" 

after  REG  DELAY; 


end  process; 
end  BEHAVIOR; 
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--  TEST  BENCH  for  HAYES  SIMPLE  CPU 


PURPOSE:  Provide  the  test  bench  entity  for  the  simple 

CPU  described  by  (Hayes  1988:315).  The  test  bench 
provides  the  clock  and  process  duration  processes  for 
control  of  this  VHDL  model.  The  test  bench  is  not 
and  need  not  be  JRS  styled  VHDL. 

--  FILE:  HAYES_TEST.VHD 

AUTHOR:  Capt  Dennis  A.  Rumbley 
AFTT  Masters  Student 
AFIT/ENG  GCS-91D 

--  DATE:  15  OCT  91 

--  VERSION:  0 


library  UTIL; 

use  UTIL . Data_Types . all ; 

library  HAYES_VER5; 

use  HAYES  VERS. MACHINE  DECLARATIONS . all ; 


entity  HAYES_CPU  is 
end  HAYES_CPU; 

architecture  TEST_BENCH  of  HAYES_CPU  is 

signal  SYS_CLOCK_SIG  :  CLOCK; 

component  CPU588_COMP 

port  (  SYS_CLK  :  in  CLOCK  ); 
end  component; 

for  all:  CPU588_COMP  use  entity  HAYES_VER5 .CPU588(BEHAVIOR) ; 

begin  --  architecture  HAYES_CPU(TEST_BENCH} 

CPU588:  CPU588_COMP 

port  map  (SYS_CLK  ->  SYS_CLOCK_SIG  ); 


make_clock:  process 

begin 

SYS_CLOCK_SIG  <-  not  SYS_CLOCK_SIG 

after  hayes_ver5 . MACHINE_DECLARATIONS . CLK_PERI0D/2 ; 
wait  for  hayes_ver5 . MACHINE_DECLARATIONS . CLK_PERI0D/2  ; 
end  process  ; 

start_stop:  process 
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begin 


wait  for  7000  ns  ; 
assert  false 

report  "End  of  Simulation" 
severity  error; 
end  process; 

end  TEST  BENCH; 
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Appendix  B 
FPASP  Design  Code 


The  Floating  Point  Application  Specific  Processor 
(FPASP)  is  a  United  States  Air  Force  research  and  develop¬ 
ment  effort.  The  design  is  therefore  proprietary  to  the 
United  States  Air  Force.  The  code  of  this  appendix  is  part 
of  that  design,  and  therefore  must  be  restricted  from  dis¬ 
tribution  to  the  general  public. 

The  FPASP  code  which  would  normally  be  found  in  this 
appendix  is  maintained  in  Volume  II  of  this  thesis.  The 
controlling  office  for  release  of  the  FPASP  information  in 
Volume  II  is; 

Rome  Laboratory 

RL/OCTS 

Griffiss  AFB,  NY 
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Appendix  C 

Stylized  FPASP  Design  Code 

The  Floating  Point  Application  Specific  Processor 
(FPASP)  is  a  United  States  Air  Force  research  and  develop¬ 
ment  effort.  The  design  is  therefore  proprietary  to  the 
United  States  Air  Force.  The  translated  code  of  this  appen¬ 
dix  used  part  of  that  design,  and  therefore  must  be  re¬ 
stricted  from  distribution  to  the  general  public. 

The  translated  FPASP  code  which  would  normally  be  found 
in  this  appendix  is  maintained  in  Volume  II  of  this  thesis. 
The  controlling  office  for  release  of  the  results  of  Style-V 
translated  FPASP  code  in  Volume  II  is: 

Rome  Laboratory 

RL/OCTS 

Griffiss  AFB,  NY 
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Appendix  D 

CASE  TO  IF  Conversion  Module 


This  appendix  contains  the  pseudo  code  and  C  code  for 
the  CASE_TO_IF  conversion  module  of  the  Style-V  translator 
and  some  test  results.  Sample  output  is  located  in  Section 
1  of  Appendix  C. 


SECTION 

TOPIC 

PAGE 

1 

Pseudo  Code 

D.  2 

2 

C  Code 

D.7 

3 

Test  Files  and  Results 

D.21 
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SECTION  1:  PSEUDOCODE 


/*  Pseudo  code  for  the  CASE  statement  to  IP  statement  conversion 

function  required  for  the  STYLE-V  translator.  This  module  provides 
one  of  the  conversions  necessary  to  convert  IEEE  standard  VHDL  into 
the  JRS  stylized  VHDL  for  input  into  the  Integrated  Design  Automation 
System . 


It  may  be  possible  to  implement  the  following  functions  using  the  LEX 
tool . 


********************************************************************* 

*  The  following  function  processes  an  input  file  to  the  point  where 

*  a  CASE  statement  is  found.  Control  is  then  passed  to  a  special 

*  function  designed  to  convert  the  CASE  statement  to  an  IF  statement. 

*  Once  the  conversion  of  the  CASE  statement  is  complete,  processing 

*  returns  to  this  function.  Each  CASE  statement  is  processed 

*  in  this  manner  for  the  entire  file.  The  resulting  output  file 

*  is  named  NC_orig_f ile_name  to  identify  the  changed  file.  Control 

*  then  passes  to  the  calling  function.  For  exeimple,  this  function 

*  will  handle  all  statements  represented  as  ! !  below  and  would  call 

*  CONV_CASE_TO_IF  to  handle  the  CASE  statements.  (Note:  comments  are 

*  passed  through  and  do  not  affect  the  translation.) 

* 

*  BEGIN  FILE 

*  !  ! 

*  !  ! 

*  !  I 

*  CASE 

*  $$ 

*  $$ 

*  CASE 

*  $$ 

*  $$ 

*  END  CASE 

*  $$ 

*  END  CASE 

*  !  ! 

*  !  ! 

*  CASE 

*  $$ 

*  $$ 

*  END  CASE 

*  I  ! 

*  END  PILE 

************************************************************************** 

*/ 

/* 
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function  CASE_T0_1P_C0NV  (in_file) 
open  in_file 
create  out_file 

niove_white_space  (in_file,  out_file) 
read_word  (in_file,  the_word) 
while  not  eof  in_file 

if  the_word  -  "case"  or  "CASE" 
then  CONV_CASE_TO_IF 

else  write_to_f ile  {out_file,  the_word) 

end  if 

move_white_space  (in_file,  out_file) 
read_word  (in_file,  the_word) 
end  while  not  eof  in_file 
close  in_file 
close  out_file 
end  CASE  TO  IF  CONV 


function  CONV  CASE  TO  IF 


"case  "  =>  "if  " 


write_to_f ile  (out_file,  "if  ") 


-  -  Pass  conditional  argument  through 


move_white_space  (in_file,  out_file) 
read_word  (in_file,  the_word) 
COND_ARG  :=  the_word 
write_to_f ile  (out_file,  COND_ARG) 


Pass  nothing  through  for  "is  " 


move_white_space  (in_file,  out_file) 
readword  (in_file,  the_word) 
if  the_word  not=  "is  "  or  "IS  " 
then  print  error  message 

set  global  error  flag 
exit  CONV_CASE_TO_IF 

end  if 


"when  "  becomes  "•=  " 


move_white_space  (in_file,  out_file) 
read_word  (in_file,  the_word) 
if  the_word  “  "when  "  or  "WHEN  " 
then  write_to_file  ("-  ") 
else  print  error  message 

set  global  error  flag 
exit  CONV_CASE_TO_IF 

end  if 
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Pass  conditional  value  through 


move_white_space  (in_file,  out_file) 
read_word  (in_file,  the_word) 
write_to_f ile  (out_file,  the_word) 


--  «=>  ■'  becomes  "then  " 


move_white_space  (in_file,  out_file) 
read_word  (in_file,  the_word) 
if  the_word  =  "=>  " 

then  write_to__f ile  (out_file,  "then  ") 
else  print  error  message 

set  global  error  flag 
exit  CONV_CASE_TO_IF 

end  if 


--  Process  when  clause  statements  to  out  file 


prev_word  :=  the_word 

(**  needed  to  exit  case  processing  **) 
move_white_space  (in_file,  out_file) 
read_word  (in_file,  the_word) 
while  the_word  not”  "when  "  or  "WHEN  " 

if  the_word  not=  "case"  or  "CASE" 

then  write_to_f ile  (out_file,  the_word) 
else  if  prev_word  ”  "end  "  or  "END  " 
then  exit  CONV_CASE_TO_IF 
else  CONV_CASE_TO_IF 

end  if 

prev_word  : =  the_word 
move_white_space  (in_file,  out_file) 
read_word  (in_file,  the_word) 
end  while  the  word  not”  "when  "  or  "WHEN  " 


--  Pass  nothing  when  next  "when  "  seen 


loop  (*  process  when  statements  until  done  *) 
prev_word  : «  the_word 


--  Check  if  next  word  is  "others" 


move_white_space  (in_file,  out_file) 
read_word  (in_file,  the_word) 
if  the_word  not-  "others  "  or  "OTHERS  " 

then  write_to_f ile  (out_file,  "elsif  ") 
write_to_f ile  (out_file,  COND_ARG) 
write_to_f ile  (out_file,  "  - 
write_to_f ile  (out_file,  the_word) 


--  "=>  "  becomes  "then  " 
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else 


move_white_space  (in_file,  out_file) 
read_word  (in_file,  the_word) 
if  the_word  -  "-=>  " 

then  write_to_f ile  (out_file,  "then 
else  print  error  message 
set  global  error  flag 


exit  CONV_CASE_TO_IF 

end  if 

write_to_f ile  {out_file,  "else  " 
move_white_space  (in_file,  out_file) 
read_word  (in_file,  the_word) 
if  the_word  not=  "=>  " 

then  print  error  message 

set  global  error  flag 
exit  CONV_CASE_TO_IF 

end  if 


") 


end  if 


Process  when  clause  statements 


prev_word  : -  the_word 
move_white_space  (in_file,  out_file) 

/  read_word  (in_file,  the_word) 

while  the_word  not=  "when  "  or  "WHEN  " 
if  the_word  not=  "case"  or  "CASE" 

then  write_to_f ile  (out_file,  the_word) 
else  if  prev_word  ”  "end  "  or  "END  " 
then  exit  CONV_CASE_TO_IF 
else  CONV_CASE_TO_IF 

end  if 

prev_word  : -  the_word 
move_white_space  (in_file,  out_file) 
read_word  (in_file,  the_word) 
end  while  the_word  not=  "when  "  or  "WHEN  " 
end  loop  (*  process  when  stmts  until  done  *) 

end  CONV  CASE  TO  IF 


function  READ_WORD  (in_file,  the_word) 
the_word  "" 

get  char  (infile,  the_char) 
while  the_char  =  "-" 

(♦♦check  for  comment^^) 
temp_char  : -  the_char 
get_char  (infile,  the_char) 
if  the_char  -  "-" 

then  the  word  : -  the_word  +  " -  - " 
while  not  end_of_line 

get_char  (in_file,  the_char) 
the_word  the_word+the_char 
end  while 
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write_word  {out_file,  the_word) 
get_char  (in_file,  thechar) 
else  the_word  :=  the_word  + 

end  if 
end  while 

while  not  eof  and  the_char  not-  blank  or  tab  or  new- line 
the_word  : -  the_word+the_char 
get_char  (in_file,  the_char) 
end  while 

the_word  : -  the_word+blank 
end  READ_WORD 

function  MOVE_WHITE_SPACE  (in_file,  out_file) 
get_char  (in_file,  the_char) 

while  not  eof  and  the_char  =  blank  or  tab  or  new- line 
put_char  (out_file,  the_char) 
get_char  (in_file,  the_char) 
end  while 
if  eof  (in_file) 

then  terminate  successfully 

else  (*  move  file  pointer  back  one  character  *) 
return_char  (in_file,  the_char) 
end  MOVE_WHITE_SPACE 

function  WRITE_TO_FILE  (out_file,  the_word) 
write_word  (out_file,  the_word) 
move_white_space  (in_file,  out_file) 
end  WRITE_TO_FILE 

*/ 
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SECTION  2:  C  CODE 


/*********«***********«******************«***************************** 

*********************************************************************** 

*************************  CASETOI  F  ***************************** 
*********************************************************************** 
*********************************************************************** 

********************************************************************** 

*  PURPOSE:  Copy  an  input  file  to  an  output  file  except  that  all  case 

*  statements  of  the  input  file  will  be  converted  to  equivalent 

*  if -elsif -else  statements.  This  program  will  handle  all  files 

*  that  match  the  following  abstract  model.  Note  that  CASETOIF 

*  handles  simple  and  nested  case  statements . 

* 

*  BEGIN  FILE 

*  !  ! 

*  1  ! 

*  t  I 

*  CASE 

*  $$ 

*  $$ 

*  CASE 

*  $$ 

*  $$ 

♦  END  CASE 


* 

$$ 

* 

END  CASE 

* 

1  1 

* 

1  1 

* 

CASE 

* 

$$ 

$$ 

* 

END  CASE 

* 

!  1 

•k 

END  FILE 

********************************************************************** 

*/ 

Sinclude  <io.h> 

#include  <stdio.h> 

#include  <string.h> 

/*  GLOBAL  VARIABLES  */ 
int  pgm_success  -  1; 
char  ♦the_word  - 

/********************************************************** 

*  FUNCTION:  FATAL_CASE_WORD_ERROR 
********************************************************** 

*  PURPOSE:  Print  error  message  for  fatal  error  when  an 
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incorrect  word  for  the  context  is  found, 
rtlso,  sets  the  global  pgin_success  flag  to  0. 


CALLED  BY:  conv  case  to  if 


CALLS : 


PARAMETERS : 

error_word  --a  character  string  which  was 
the  offending  word. 

LOCAL  VARIABLES: 

in_str[132]  :  string  used  to  load  input  param 
string.  Used  to  limit  the  number  of 
pointer  strings  because  of  overwrite 
problems  when  using  pointer  strings . 

GLOBAL  VARIABLES; 

pgmsuccess  --  used  to  show  a  condition  has 
occurred  which  causes  abnormal 
program  termination. 

AUTHOR:  Capt  Dennis  A.  Rumbley 

AFIT  Masters  Student 

AFIT/ENG,  GCS-91D 


20  Sep  91 


*  VERSION:  1 

********************************************************** 

*/ 

void  f atal_case_word_error  (char  *error_word) 

{ 

char  in_str[132]  - 

strcpy( instr ,  error_word) ; 

puts 

("***  Now  entering  FATAL_CASE_WORD_ERROR  function  ***") 
printf ( "\n\tWord  other  than  %s",  in_str,  "  found  " ) ; 
printf("in  textual  context  of  CASE  statement  I ") ; 
printf ( "\n\t***FATAL  ERROR***" ) ; 
printf ( "\n\n" ) ; 

pgmsuccess  -  0;  /*  abnormal  terminate  */ 

puts 

("***  Now  leaving  FATAL_CASE_WORD_ERROR  function  ***"); 
}  /*  end  f atalcaseworderror  */ 


*  FUNCTION:  READ_WORD_OR_PASS  {in_file,  outfile) 


*  PURPOSE:  It  gets  the  next  word  from  the  input  file.  A  word 
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* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 


starts  with  a  letter  or  quote  and  can  contain  underscores . 
For  this  program  READ_WORD_OR_PASS  also  recognizes  a 
special  word  Any  nonword  or  whitespace  found  is 

passed  to  the  output  file. 


CALLED  BY; 


CALLS : 


conv_case_to_if 

case_to_if_conv 

none 


LOCAL  VARIABLES: 

thechar  :  a  character  var  used  to  read  a 
char-at-a-time  from  the  input  file. 
a_word  ;  a  character  array  used  to  collect 
chars  to  form  words  from  the  input, 
index  :  the  index  for  the  a_word  char  array. 

GLOBAL  VARIABLES: 

the_word  :  used  to  update  the  current  word 
for  use  by  the  calling  functions. 


AUTHOR : 


DATE: 


VERSION; 


Capt  Dennis  A.  Rumbley 
AFIT  Masters  Student 
AFIT/ENG,  GCS-91D 

20  Sep  91 


*************************************************************** 

*/ 

void  read_word_or_pass  (FILE  *in_file,  FILE  *out_file) 

{ 

/*  variable  declarations  */ 
char  the_char  ”  '  ' ; 
char  a_word[132]  = 
int  index  -  0; 

/*  processing  statements  */ 

strcpy  {the_word, 

thechar  -  fgetc  (infile); 


/*  read  characters  until  a  valid  character  to  start  a  word  */ 
while  (Ifeof  (in_file)  && 

(thechar  <  'A'  | ] 

(thechar  >  'Z'  &&  the_char  <  'a')  || 
thechar  >  'z')) 


{ 


/*  return  string  literals  */ 
if  (thechar  ~ 


{ 


) 


aword [ index++]  -  ' " ' ; 
the_char  -  fgetc  (in  file); 
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f  n  / 


) 


while  {the_char  != 

{ 

a_word[index++]  “  the_char; 
the_char  =  fgetc  (in_file); 

} 

a_word[ index]  = 
strcpy  (the_word,  a_word) ; 
the_char  =  fgetc  (in_file); 
break; 


} 

/*  look  for  process  comment  state  */ 
if  (the_char  == 

{ 

the_char  -  fgetc  (in_file); 
if  (the_char  == 

{ 

fputs  out_file)  ; 

the_char  =  fgetc  (in_file); 
hile  (ffeof  (in_file) 

&&  the_char  !=  '\n') 

{ 

fputc  (the_char,  out_file) ; 
the_char  *  fgetc  (in_file); 

} 


} 

else  fputc  out_file); 

) 

/*  look  for  becomes  symbol  state  */ 
if  (the_char  '=') 

{ 

the_char  =  fgetc  (in_file); 
if  (the_char  =•=  '>') 

{ 

strcpy  (a_word,  "=>"); 
the_char  =  fgetc  (in_file); 
break; 


} 

else  fputc  out_file); 

} 

/*  if  not  comment,  becomes,  or  string  lit  pass  */ 
if  ((the_char  !=  &&  {the_char  !-  '«')  && 

( the_char  !  ■= 

( 

fputc  (the_char,  out_file); 
the_char  -  fgetc  (in_file); 

) 

/*  end  while  char  not  legal  to  start  a  word  */ 


/*  now  process  a  regular  word  state  */ 
while  (Ifeof  (in_file)  && 

((the_char  >=  'A'  &&  the_char  <-  'Z')  || 
(the_char  >-  'a'  &&  the_char  <-  ' z' )  || 
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the  char 


a_word[index++]  =  the_char; 
the_char  -  fgetc  (in_file); 

) 

/*  restore  file  to  read-a-word  state  */ 
if  (Ifeof  (iti_file)) 

ungetc  (the_char,  in_file); 

/*  copy  local  value  ro  global  variable  */ 
strcpy  (the_word,  a_word); 

}  /*  end  read_word_or_pass  */ 


/*****’***********************'4r*****************'»******'* 

*  FUNCTION:  READ_COND_VALUE  (INPUT_FILE,  OTHERS_PLAG) 

ifit*****************-^*********************************** 

*  PURPOSE:  It  gets  the  next  word  from  the  input  file.  A  word 

*  starts  with  a  letter  or  quote  and  can  contain  underscores . 

*  For  this  program  READ_WORD_OR_PASS  also  recognizes  a 

*  special  word  Any  nonword  or  whitespace  found  is 

*  passed  to  the  output  file. 

* 

*  LOCAL  VARIABLES : 

*  a_char  :  a  character  var  used  to  read  a 

*  char-at-a-time  from  the  input  file. 

*  a_word[132]  ;  a  character  array  used  to  collect 

*  chars  to  form  words  from  the  input . 

*  other_word[7]  :  a  character  array  used  to  check 


* 

if  the  input  word  was  " 

others" 

or  not 

* 

index  :  the  index  for  the  a_word  char 

array. 

GLOBAL  VARIABLES: 

♦ 

the_word  :  used  to  update  the 

current 

word 

★ 

it 

for  use  by  the  calling 

functions . 

★ 

CALLED  BY: 

conv_case_to_if 

■ 

★ 

it 

CALLS : 

none 

* 

AUTHOR : 

Capt  Dennis  A.  Rumbley 

* 

AFIT  Masters  Student 

* 

it 

APIT/ENG,  GCS-91D 

* 

it 

DATE: 

20  Sep  91 

* 

VERSION: 

1 

*************************************************************** 

*/ 

void  read_cond_value  (PILE  *in_file,  char  *others_found) 
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/*  local  variables  */ 
char  a_char  =  ' '  ; 
char  a_word[132]  - 
char  other_word [ 7 ]  -  ; 

int  index  -  0; 

/*  process  statements  */ 
a_char  -  fgetc  (in_file); 

/*  strip  whitespace  from  front  of  condition  value  */ 
while  (Ifeof  (in_file)  &&  (a_char  ==  '  '  || 
a  char  --  '\t'  ||  achar  =-  '\n')) 
a_char  -  fgetc  (in_file); 

/*  get  condition  value  string  */ 
while  (!feof  (in_file)  &&  a_char  != 

/*  the  first  symbol  of  "=>"  */ 

{ 

a_word[index++]  =  a_char; 
a_char  =  fgetc  {in_file); 

} 

if  (Ifeof  (in_file))  ungetc  (a_char,  in_file); 
strcpy  (the_word,  a_word); 

/*  check  if  other  found  */ 

index  -  0; 

while  (index  <-  5) 

{ 

other_word( index]  -  a_word [ index]  ; 

++index; 

} 

if  (Istrcmpi  (other_word,  "others")) 

strcpy  (others_found,  "true"); 
else  strcpy  (others_found,  "false"); 

]  /*  end  read_cond_value  */ 


y'*  *************************************************** 

*  FUNCTION:  CONV_CASE_TO_IF 

*  PURPOSE:  Converts  case  statements  to  if  statements. 

*  When  called,  a  word  "case"  has  been  read  by 

*  the  calling  function.  The  case  argument  is  read, 

*  "is"  and  "when"  are  passed  thorough,  and  the  first 

*  condition  value  is  read.  The  if_clause  is  now 

*  generated.  The  "->"  symbol  is  read  but  nothing  output. 

*  The  "when_clause"  is  now  processed.  All  the  words  of 

*  the  when  clause  are  passed  to  the  output  file  with  the 

*  exception  of  the  word  "case"  which  if  not  preceded  by 
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"end"  causes  a  recursive  call  to  conv_case_to_if . 

When  the  next  "when"  is  seen,  the  condition  value  is 
read,  and  if  not  equal  to  "others"  an  elsif_clause  is 
generated  and  processed  similarly  to  the  if_clause.  If 
the  condition  value  is  "others"  an  else_clause  is 
generated . 


*  PARAMETERS : 

*  in_file  :  a  pointer  to  the  input  file. 

*  out_file  :  a  pointer  to  the  output  file) 

* 


* 

★ 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 


LOCAL  VARIABLES: 

cond_arg [132]  :  a  string  to  hold  the  case  argument 
cond_value [132]  :  a  string  to  hold  the  representation 

of  the  current  value  of  the  case  argument  during 
the  conversion  process . 

*others_found  ;  a  string  pointer  used  to  check  if  the 
word  "others"  has  been  found. 
prev_word [132]  :  a  string  ptr  used  to  track  the  word 

processed  just  before  the  current  word  during 
the  converion  process .  Critical  to  recognize 
the  "end  case"  phrase  signaling  the  conversion 
is  complete  and  only  "if"  needs  to  be  written. 


*  GLOBAL  VARIABLES : 

*  the_word  :  a  string  pointer  used  to  contain  the  current 

*  word  being  processed  during  the  convert  process . 

* 

*  FUNCTIONS  CALLED : 

*  fatal_case_word_error  (char  *); 

*  read_word_or_pass  (PILE  *,  FILE  *); 

*  read_cond_value  (PILE  *,  char  *); 

* 

*  CALLED  BY :  case_to_if_conv 

*  conv_case_to_if 

* 

*  USE  OF  GOTO:  The  goto  statement  is  used  only  to  emulate  the 

*  Ada-type  EXIT  statement.  The  C  break  statement  only  exits 

*  a  loop,  not  necessarily  a  function.  The  use  of  goto  is 

*  limited  to  goto  EXIT_CONV_CASE_TO_IF  which  is  located  at 

*  the  end  of  the  function. 


*  AUTHOR:  Capt  Dennis  A.  Rumbley 

*  AFIT  Masters  Student 

*  AFIT/ENG,  GCS-91D 


*  DATE:  20  Sep  91 

* 

*  VERSION:  1 

****•**********«****«************•***************'»******** 


*/ 
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void  conv_case_to_if  (FILE  FILE  *out_file) 

{ 

/*  called  functions 

void  f atal_case_word_error  (char  *); 
void  read_word_or_pass  (FILE  *,  PILE  *); 
void  read_cond_value  (FILE  »,  char  *); 

*/ 


/*  variable  declaration  section  */ 

char  cond_arg [132]  = 
char  cond_value[132]  = 
char  *others_found  -  "false"; 
char  prev_word [132]  - 

/*  function  statements  section  */ 

/*  begin  building  if  clause  */ 
read_word_or_pass  (in_file,  out_file); 
strcpy  (cond_arg,  the_word); 

/*  read  IS  but  pass  nothing  for  it  */ 
read_word_or_pass  (in_file,  out_file) ; 
if  (strcmpi  (the_word,  "is"))  /*  the_word  J=  "is"  */ 

{ 

fatal_case_word_error  ("  IS  " ) ; 
goto  EXIT_CONV_CASE_TO_IF; 

) 

/*  read  WHEN  but  pass  nothing  for  it  */ 
read_word_or_pass  (in_file,  out_file); 
if  (strcmpi  (the_word,  "when")) 

/*  theword  I-  "when"  */ 

{ 

fatal_case_word_error  ( "WHEN" ) ; 
goto  EXIT_CONV_CASE_TO_IF; 

) 

/*  read  the  conditional  value  for  the  if_clause  */ 
read_cond_value  (in_file,  others_found) ; 
strcpy  (cond_value,  the_word); 

/*  read  becomes  symbol  and  pass  THEN  for  it  */ 

read_word_or_pass  (in_file,  out_file); 

if  (strcmp  (the_word,  "->"))  /*  the_word  t=  "->"  */ 

{ 

f atal_case_word_error  ("->") ; 
goto  EXIT_CONV_CASE_TO_IF; 

1 

/*  write  if_clause  to  output  */ 
fputs  ("if  ",  out_file); 
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fputs  (cond_arg,  out_file); 
fputs  out_file); 

fputs  (cond_value,  out^file); 
fputs  ("  then  ",  out_file); 


/*  read  if_clause  (when)  body  */ 
strcpy  (prev_word,  the_word); 
read_word_or_pass  {in_file,  out_file) ; 
while  (strcmpi  (the_word,  "when")) 

/*  the_word  ! - 


{ 


"when"  */ 


if  (strcmpi  (the_word,  "case")) 

/*  the_word  !=  "case"  */ 

{ 

fputs  (the_word,  out_file); 
strcpy  (prev_word,  the_word) ; 
read_word_or_pass  (in_file,  out_file); 

} 

else  if  (f strcmpi  (prev_word,  "end")) 

/*  prev_word  -=  "end"  */ 

{ 

fputs  ("if",  out_file); 
goto  EXIT_CONV_CASE_TO_IF; 

) 

else  /*  new  case  statement  encountered  */ 
conv_case_to_if  (in_file,  out_file); 

) 

y  **************  4r  «*******♦****#*  4r  **********  ♦ 


*  second  when  now  seen,  ready  to  process  elsif 

*  or  else  clauses,  can  determine  which  when 

*  read_cond_value  returns . 

*********************************************** 


*/ 

do 


{ 


read_cond_value  (in_file,  others_found) ; 
if  (strcmpi  (others_found,  "true”)) 

/*  others_found  !-  "true"  */ 

{ 


strcpy  (cond_value,  the_word); 


/*  read  becomes  symbol  and  pass  THEN  in  the  clause  */ 
read_word_or_pass  (in_file,  out_file); 
if  (strcmp  (theword,  "->")) 

/*  the_word  I-  "=>"  */ 

{ 

f atal_case_word_error  ("->"); 
goto  EXI T_CONV_CAS  E_TO_I F ; 


/*  write  elsif_clause  to  output  */ 
fputs  ("elsif  ",  out_file); 
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fputs  (cond_arg,  out_file) ; 
fputs  ("  =  ",  out_file); 
fputs  (cond_value,  out_file); 
fputs  ("  then  ",  out_file); 


} 

else 

I 


/*  read  elsif_clause  (when)  body  */ 
strcpy  (prev_word,  the_word) ; 
read_word_or_pass  {in_file,  out_file); 
while  (strcmpi  (the_word,  "when")) 

/*  the_word  I = 


{ 


"when" 


if  (strcmpi  (the_word,  "case")) 
/*  the_word  1“=  "case"  */ 

{ 


*/ 


fputs  (the_word,  out_file); 
strcpy  (prev_word,  the_word); 
read_word_or_pass  (in_file,  out_file); 

} 

else  if  (tstrcmpi  (prev_word,  "end")) 

/*  prev_word  ==  "end"  */ 

{ 

fputs  ("if",  out_file); 
strcpy  (the_word,  ""); 
goto  EXIT_CONV_CASE_TO_IF; 

} 

else  /*  new  case  stmt  encountered  */ 
conv_case_to_if  (in_file,  out_file); 


/*  "others"  was  seen  --  process  else  statement  */ 


/*  read  becomes  symbol  and  pass  nothing  for  it 
read_word_or_pass  (in_file,  out_file); 
if  (strcmp  (the_word,  "«>")) 

/*  the_word  !=  "=>" 


{ 

f atal_case_word_error  ("->"); 
goto  EXIT_CONV_CASE_TO_IF; 

) 


*/ 


*/ 


/*  write  else_clause  to  output  */ 
fputs  ("else  ",  out_file); 


/*  read  else_clause  (when)  body  */ 
strcpy  (prev_word,  the_word); 
read_word_or_pass  (in_file,  out_file); 
while  (strcmpi  (theword,  "when")) 

/*  the_word  ! - 


{ 


"when" 


if  (strcmpi  (the_word,  "case")) 
/*  theword  !-  "case"  */ 

{ 


*/ 
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fputs  (the_word,  out_file); 
strcpy  (prev_word,  the_word); 
read_word_or_pass  (in_file,  out_file); 

} 

else  if  (Istrcmpi  (prev_word,  "end")) 

/*  prev_word  --  "end"  */ 

{ 

fputs  ("if",  out_file); 
strcpy  (the_word,  ""); 
goto  EXIT_CONV_CASE_TO_IF; 

} 

else  /*  new  case  stmnt  encountered  */ 
conv_case_to_if  (in_file,  out_file); 


} 


] 


}  while  (Istrcmp  (others_found,  "false")); 

/*  others_found  —  false  */ 
EXIT_CONV_CASE_TO_IF:  strcpy  (others_found,  "false"); 

/*  needed  due  to  recursion  */ 

)  /*  end  conv  case  to_if  */ 


y***********it'****  **«-**********«*************************** 

*  FUNCTION:  CASE_TO_IF_CONV  (input_file,  output_file) 

********************************************************** 

*  PURPOSE:  Reads  an  input  file  and  passes  words  read  to 

*  an  output  file  until  a  word  "case"  is  read.  At 

*  that  point,  "case"  is  not  passed  to  the  output. 

*  Instead,  conv_case_to_if  is  called  to  convert  the 

*  case  statement  to  an  if  statement.  Then  control 

*  returns  to  this  function. 

* 

*  PARAMETERS : 

*  infile  :  a  string  value  (the  name  of  the  input  file) 

*  outfile  :  a  string  value  (the  name  of  the  output  file) 

* 

*  LOCAL  VARIABLES: 

*  in_file  :  a  string  pointer  used  to  identify  the 
input  file  to  function  case_to_if_conv . 

outfile  :  a  string  pointer  used  to  identify  the 
output  file  to  function  case_to_if_conf . 


*  GLOBAL  VARIABLES : 

*  pgm_success  :  an  integer  which  if  0  tells  that 

*  the  program  was  not  successful. 

*  the_word  :  a  string  pointer  used  to  contain  the  current 

*  word  being  processed  during  the  convert  process . 


FUNCTIONS  CALLED: 


conv_case_to_i f 
read_word_or_pass 


CALLED  BY:  main 
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★ 

* 

AUTHOR ; 

Capt  Dennis  A.  Rumbley 

★ 

AFIT  Masters  Student 

it 

it 

AFIT/ENG,  GCS-91D 

it 

if 

DATE: 

20  Sep  91 

it 

VERSION: 

1 

H********************************************************-*! 

*/ 

void  case_to_if_conv  (char  *infile,  char  *outfile) 

{ 

/*********************************/ 

/*  variable  declarations  section  */ 


/* 

*/ 


/*  called  functions  declarations  */ 
void  conv_case_to_if  (FILE  *,  PILE  *); 
void  read_word_or_pass  (FILE  *,  FILE  *); 

/*  internal  file  identifiers  */ 

FILE  *in_file; 

FILE  *out_file; 

y********************************* y 

/*  function  statements  section  */ 

/*  open  files 
*/ 

in_file  -  fopen  (infile,  "rt"); 
out_file  -  fopen  (outfile,  "wt"); 

/*  move  words  and  nonwords  to  output 

until  a  case  statement  is  encountered, 
the  end  of  the  input  file  is  reached, 
or  an  abnormal  condition  causes  unsuccessful 
program  termination . 

*/ 


read_word_or_pass  (in_file,  out_file); 
while  (Ifeof  (in_file)  &&  pgm_success  — ■  1) 

{ 

/*  function  strcmp  required  to  see  if  the_word 
is  equal  to  a  given  string.  If  so,  strcmp 
returns  a  0.  Must  not  (!)  strcmp  to  get  a 
"true"  (1)  reply  when  the  stings  are  equal 

*/ 

if  /*  theword  "case"  */ 

(Istrcmpi  (the_word,  "case")) 

conv_case_to_if  (in_file,  out_file) ; 

else 

{ 

fputs  (the_word,  out_file); 


D.18 


1 


} 

}  /*  while  !  eof  ( in_f ile_handle)  or  pgin_success  - 

/*  close  files  after  processing 
*/ 

fclose  (in_file); 
fclose  (out_file); 

}  /*  end  CASE  TO  IP  CONV  */ 


y/*  ******  4r  ******  *  4r  ***  *******************  ***  4  ♦♦***  * 

*  FUNCTION;  MAIN 

********************************************************** 

*  PURPOSE:  Driver  routine  for  progreun  to  convert  case 

*  statements  in  an  input  file  to  if  statements 

*  in  an  output  file. 

* 


*  PARAMETERS : 

*  argc  :  an  integer  that  tells  how  many  arguments 

*  are  on  the  command  line  (incl  pgm  name) 

*  argv[]  :  a  string  array  of  arguments  on  the  cmd 

*  line.  The  number  of  these  arguments  is 

*  argc  -  1 . 

* 

*  LOCAL  VARIABLES : 

*  in_file  ;  a  string  pointer  used  to  identify  the 
input  file  to  function  case_to_if_conv . 

out_file  :  a  string  pointer  used  to  identify  the 
output  file  to  function  case  to  if  conf. 


GLOBAL  VARIABLES: 

pgm_success  :  an  integer  which  if  0  tells  that 
the  progreun  was  not  successful. 

FUNCTIONS  CALLED:  case_to_if_conv 

CALLED  BY:  none 


AUTHOR : 


DATE: 


Capt  Dennis  A.  Rumbley 
AFIT  Masters  Student 
AFIT/ENG,  GCS-91D 

20  Sep  91 


VERSION:  1 


int  main  (int  argc,  char  *argv[]) 

{ 


/*  variable  declarations  section  */ 


/* 

V 


char  *in_file  - 
char  *out_file  - 

void  case_to_if_conv  (char  *,  char  * )  ; 


/* 

if 

{ 


} 

if 

{ 


program  statements  */ 
(argc  !-  3) 


puts  ("**♦***  ERROR:  Wrong  Number  of  Files  on 

Command  Line  ******\n"); 
puts  ("  ***  Please  enter  the  name  of  your  input 

file  and  a  name\n”); 
puts  ("  ***  for  the  output  file.  EX.  casetoif 

in_fil  outf il\n\n\n " ) ; 


pgm_success  -  0; 


(pgm_success  — =  1) 


in_file  -  argv[l]; 
out_file  =  argv[2]; 

puts  ("Now  converting  CASE  statements  in  file  "); 
puts  (in_file); 

puts  ("\nto  IF  statements  in  a  file  called  "); 
puts  (out_file); 
puts  ("\n\n"); 

case_to_if_conv  (in_file,  out_file); 

puts  ("***  Thank  you  for  using  CASET01P.EXE  ***\n\n\n" ) ; 

) 


if  (pgm_success  --  1) 
return  0; 


else 


{ 

puts  ("***  ABNORMAL  PROGRAM  RUN  ***"); 
return  1; 

} 

/*  end  main  */ 
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SECTION  3:  TEST  FILES  AND  RESULTS 


TEST  1 

—  ********************************************************* 
This  is  a  file  of  conunents  and 
should  be  passed  straight  through 
—  *******************************<(*****11:******************* 

case  BOX  of 

when  crackers  =>  eatem; 
when  bolts  =>  useem; 
end  case; 


TEST  1  RESULTS 

- ********1t*********************1HHt***1t****^HHIr********'***** 

This  is  a  file  of  comments  and 
should  be  passed  straight  through 

—  *****'fc******'************it********imt*init******************* 

case  BOX  of 

when  crackers  =>  eatem; 
when  bolts  =>  useem; 
end  case; 

- -p 


TEST  2 


and 

the 

--  7789 

december 

case 

edit 

tom 

the  folks  at 
party 
end  case 
bye 


home 


TEST  2  RESULTS 


and 

the 

--  7789 
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december 


TEST  3 


--  This  file  is  to  test  if  CASETOIF.EXE  can  process  string 
--  literals 

--  that  contain  the  keyword  CASE  without  trying  to  process 

--  a  case  statement 

signall  <=  "0010"  after  10  ns; 

write  ("In  case  you  didn't  know,  signal_l  is  now  '0010'.") 
signal_2  <=  signal_l  after  50  ns; 
case  test  is 

when  1  =>  load_memory; 
when  2  =>  disable_chip; 
when  3  =>  reset_pgm_counter ; 
when  others  =>  null; 
end  case; 

write  ("That  is  the  end  of  the  CASE  file."); 


TEST  3  RESULTS 


--  This  file  is  to  test  if  CASETOIF.EXE  can  process  string 
--  literals 

--  that  contain  the  keyword  CASE  without  trying  to  process 

-  -  a  case  statement 

signal_l  <=  "0010"  after  10  ns; 

write  ("In  case  you  didn't  know,  signal_l  is  now  '0010'.") 
signal_2  <=  signall  after  50  ns; 

if  test  =  1  then  load_memory; 
elsif  test  =  2  then  disable_chip; 
elsif  test  =  3  then  reset_pgm_counter ; 
else  null; 

end  if; 

write  ("That  is  the  end  of  the  CASE  file."); 
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TEST  4 


--  This  file  contains  nested  case  statements  to  enable 
--  testing 

--of  the  CONVERT  CASE  TO  IF  program  (casetoif.exe)  for 
--  handling 
--  nested  cases. 

case  country  is 

when  USA  =>  say  "Yea!"; 
when  JAPAN  =>  say  "Aso!"; 
when  USSR  =>  case  republic  is 

when  RUSSIA  =>  say  "go  Boris!"; 

when  ESTONIA  |  LATVIA  =>  say  "Free  at  Last!"; 

when  GEORGIA  =>  say  "Civil  War!"; 

when  otHeRs  =>  say  "go  Capitalists!"; 

end  case; 

say  "Communism  never  had  a  chance!!!"; 
when  Others  =>  say  "Who  Cares!!!"; 

end  case; 

say  "Finished  processing  nested  cases." 
file  end. 


TEST  4  RESULTS 

--  This  file  contains  nested  case  statements  to  enable 
--  testing  of  the  CONVERT  CASE  TO  IF  program  (casetoif.exe) 
--  for  handling  nested  cases. 

if  country  =  USA  then  say  "Yea!"; 
elsif  country  =  JAPAN  then  say  "Aso!"; 
elsif  country  =  USSR  then 

if  republic  =  RUSSIA  then  say  "go  Boris!"; 
elsif  republic  =  ESTONIA  |  LATVIA  then  say  "Free 
at  Last! " ; 

elsif  republic  =  GEORGIA  then  say  "Civil  War!"; 
else  say  "go  Capitalists!"; 
end  if; 

say  "Communism  never  had  a  chance!!!"; 
else  say  "Who  Cares!!!"; 

end  if; 

say  "Finished  processing  nested  cases." 
file  end. 


D.23 


(Note:  May  need  to  expand  symbol  ”|"  to  "or  cond_var  = 

Will  know  more  when  run  through  IDAS.  None  of  the  FPASP 
CASE  statements  contained  this  operator,  so  VHDL  analysis 
did  not  test  for  this  case.) 

TEST  5  was  a  run  of  the  CASE_to_IF  program  against  files  of 
the  FPASP  design.  The  results  of  this  test  are  included  in 
Appendix  C . 
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